[css-sizing-3] Why was min-content, etc. redefined to do nothing in the block axis?

[cbiesinger]

https://drafts.csswg.org/css-sizing-3/#sizing-values

min-content
If specified for the inline axis, use the min-content inline size; otherwise behaves as the property’s initial value.

Why is it now defined this way (it didn't use to be)? This makes it impossible to use this property in min/max-block-size properties, which is useful.

(Chrome's UI was using it, until https://chromium-review.googlesource.com/c/chromium/src/+/1599691 broke it when we matched the spec)

[cbiesinger]

@fantasai @tabatkins

[cbiesinger]

This is now also inconsistent with flexbox's min-height: auto, which references the min-content size, which was not changed.

https://drafts.csswg.org/css-flexbox/#min-size-auto
https://drafts.csswg.org/css-sizing-3/#min-content

[Loirooriol]

Related: #3684

[mstensho]

@mstensho

[dbaron]

Do you have a link to the old definition?

[Loirooriol]

@dbaron I guess the change was 2eda98a, so previously it was

min-content
Use the min-content inline size or min-content block size, as appropriate to the writing mode.

https://drafts.csswg.org/date/2016-12-29T05:58:14/css-sizing-3/#size-keywords

[dbaron]

So given the way min-content and max-content sizes are defined, I don't think it's clear what that means, since the size of a float in the block dimension depends on the inline-size of its containing block, and this definition doesn't say what inline-size to use. Then again, this lack of clear definition of intrinsic sizes in the block dimension is a longstanding problem; see #2890.

I would definitely by opposed to adding this back if the behavior isn't clearly defined. (If it is defined, then my position likely depends on the definition.) I think defining it requires at a minimum fixing #2890.)

[css-meeting-bot]

The CSS Working Group just discussed why was min-content redefined to do nothing on the block axis?, and agreed to the following:

• RESOLVED: cbiesinger will document chrome's behavior and we will revisit

The full IRC log of that discussion

<fremy> Topic: why was min-content redefined to do nothing on the block axis?
<fremy> fantasai: since christian raised this issue, it would be good to have him on the line when we discuss this?
<fremy> fantasai: (this was a question)
<fremy> astearns: we could move to the next one to see if we can get christian on the line?
<fantasai> cbiesinger: ping
<fremy> iank_: (pinging christian on slack)
<fremy> (cbiesinger dialing in)
<fremy> <br type="technical" /> ;-)
<fremy> astearns: cbiesinger can you summarize the issue?
<fremy> cbiesinger: there was a change in css-sizing spec
<fremy> cbiesinger: now min-content does the same as the initial value
<astearns> github: https://github.com//issues/3973
<fremy> cbiesinger: which is great for height
<fremy> cbiesinger: but for min-height for instance, this is a change in behavior
<fremy> cbiesinger: and in flexbox with auto, you can't get a specific effect that you used to get before
<fremy> cbiesinger: so we should probably redefine it again so that it does a different thing by property
<fremy> fantasai: makes sense to me
<fremy> dbaron: the assumption is that it was defined before
<fremy> dbaron: but before it wasn't clear to me what it was actually supposed to do
<fremy> dbaron: you have block size that is derived from the content
<fremy> dbaron: but it doesn't say which inline size is used to get that layout done
<fremy> dbaron: so in the general case, what would be that inline size?
<fremy> dbaron: is that a function of something else? how does it get passed in to this?
<fremy> cbiesinger: yay, that's true
<fremy> cbiesinger: the definition of the min-content block size still exists in the spec though
<fremy> cbiesinger: and it has this issue, so we need to fix this no matter what
<fremy> dbaron: sure, but I'm not sure we should have this in the spec at all
<AmeliaBR> min-content block size definition: https://drafts.csswg.org/css-sizing-3/#min-content-block-size
<fremy> cbiesinger: in the common case in a column-flexbox, it defaults to min-height, min-content
<fremy> dbaron: and how do you determine what that height is?
<fremy> cbiesinger: you use the inline size you derive from the sizing properties
<fremy> dbaron: so it's not really an intrinsic size, it's a specific size that depends on the layout you are in the middle of doing
<fremy> dbaron: so we don't really need this concept for that case
<fremy> dbaron: but for othogonal flows, you'd allegedly need the general case?
<fremy> fantasai: for orthogonal flows, you have to pick a size anyway
<fremy> dbaron: so, ok, regardless, we need to define very precisely that inline size
<fremy> iank_: is it true that in our implementation, the value is (...) ?
<fremy> cbiesinger: yes, the post-layout size is (...)?
<fremy> iank_: in our implementation, min-content and max-content were the same, and were the post-layout block size of this element, as if no other constraints were applied
<fremy> ^ clarifying the ... above
<fremy> iank_: and it works thanks to the clamping
<fremy> fantasai: I think it's very clear to me that the change was not correct anyway
<fremy> fantasai: so we should revert this edit anyway
<fremy> fantasai: but I agree we should also make sure we get things defined explicitly
<fremy> fantasai: and maybe think whether min-content and max-content should be the same
<fremy> dbaron: and even if they are the same, we need to define what they are
<fremy> dbaron: but if we don't have a first-layout pass, sometimes it happens?
<fremy> iank_: for min-height/max-height you do, because you clamp an existing height
<fremy> fantasai: so, yeah, using the default value is wrong because sometimes auto is not min-content
<fremy> fantasai: I can't think of a reason for blocks to want min-content != max-content
<fremy> fantasai: maybe for grid, we could trigger the different distributions algorithms for them
<fremy> fantasai: we should think about that
<fantasai> s/maybe/but/
<fantasai> It's less clear that they should be different in this case, because there are different space distribution rules for each
<fremy> astearns: so, I hear that we want to revert, and try to get a definition for this
<fremy> astearns: even if there is some scepticism we can get a definition that works
<fremy> dbaron: I would also not want to call them intrinsic if they are not intrinsic anymore
<fremy> dbaron: it seems to me we are defining something else entirely
<fremy> dbaron: doing some of these things require major changes in some algorithms, and I'm not sure what the use cases are
<fremy> cbiesinger: min-height:min-content seems useful
<fremy> dbaron: it is not impossible that this could take a year for us to implement, and I'm not sure this is worth
<fremy> dbaron: there are some existing implementations, but did we check that they match, and not are just superficially similar
<fremy> dbaron: I am not sure
<fremy> dbaron: so I don't want to take this lightly
<fremy> dbaron: so I would rather have a full proposal
<fremy> dbaron: so I can evaluate complexity, and evaluate the cost/benefit ratio
<fremy> dbaron: there are things that happen in gecko when you specify these things of course, but are we interop? probably not?
<fremy> emilio: I don't think we have impelemnted to block size that works in the block axis
<fremy> TabAtkins: (pointing another case that seems wrong in gecko, even in the inline axis)
<fremy> cbiesinger: agrees that some cases are difficult in the inline cases
<fremy> TabAtkins: we do use an approximation here, that was better than gecko that assumes a single-column
<fremy> TabAtkins: Edge had a good implementation
<fremy> TabAtkins: but regardless, we didn't
<fremy> TabAtkins: so I tend to agree that intrinsic isn't always as "intrinsic" as the name implies
<fremy> TabAtkins: it sometimes requires full layout
<fremy> fantasai: how about changing the spec to say that we want to match the `auto` height
<fremy> fantasai: but in the sense of `auto` that computes an height
<fremy> fantasai: not like in grid where `auto` sometimes means `stretch` etc
<fantasai> s/height/height based on the content size, rather than filling the container etc./
<fremy> astearns: can we resolve of reverting?
<fremy> dbaron: I'm uncomfortable going back to undefined
<fremy> astearns: but other engines don't want that current spec text
<fremy> dbaron: ok, but this is a can of worms
<fremy> dbaron: (snarky comments about multiple engines)
<fremy> cbiesinger: I'm optimistic we could get this interoperable
<fremy> iank_: for the cases that cbiesinger described, it would be easy to implement the correct behavior for that subset
<fremy> iank_: and we think it's useful
<fremy> astearns: as you implement subset, it would be nice to describe things in details, so we could find out if interop is possible
<fremy> fantasai: technically, the behavior we want should already exist in the engine, it might not just be called in that specific scenario
<fremy> fantasai: but the keyword would allow to tap in the computations that exist
<fremy> fantasai: possibly there are cases where you would need much more layout than engines are willing to do
<fremy> fantasai: but there are a lot of reasonable cases
<fremy> fantasai: and for those cases we should figure out what should happen and standardize that
<fantasai> s/to do/to do, e.g. for the width of a multiline column flexbox/
<fremy> astearns: basically dbaron hesitates due to lack of precise details
<fremy> cbiesinger: is there a particular case you think would be very hard?
<fremy> cbiesinger: so we could find out if we could solve that one?
<fremy> dbaron: intrinsic size depending on the inline, it could depend on layout optimizations
<fremy> dbaron: and there might be cases where we try to figure out block before inline
<fremy> dbaron: and all those cases seem intricate
<fremy> fantasai: yeah, grid has two passes for that reason
<fremy> fantasai: (explains how these metrics are computed already today, she thinks)
<fremy> dbaron: I'm worried it uses a value from late in the system, early in the system
<fremy> dbaron: gladly calc doesn't allow to make computations based on those values usually
<fremy> dbaron: but there might be cases where we do this accidentally in the algorithm
<fremy> dbaron: and it might cause instability/ec
<fremy> cbiesinger: I understand the concerns now
<fremy> cbiesinger: I'm still inching towards it's sufficiently useful
<fremy> dbaron: is is sufficiently useful that you would be willing to write a spec?
<fremy> TabAtkins: (proposed to meet next time he was in new-york to work on it, but cbiesinger is not based in NY)
<fremy> cbiesinger: I will write something
<fremy> cbiesinger: I can try writing a spec
<fremy> astearns: so, first resolution attempt, can we revert what's in the spec now?
<fantasai> https://github.com//issues/3973#issuecomment-498062046
<fremy> (can we get a link to the change)
<fremy> dbaron: do we know why we made the resolution that let to this changeset?
<fremy> TabAtkins: I don't recall
<fremy> dbaron: what I don't like is that the revert will trigger chrome to revert
<fremy> dbaron: and that revert will be unspecced but people will rely on their behavior
<fremy> florian: we could have an issue in the spec
<fremy> Rossen: that seems overkill, we have an issue on github seems enough
<fremy> Rossen: I think it would be better to first get a strawman of the chrome behavior, and we can resolve the revert at that time
<fremy> cbiesinger: ok, sounds fine
<fremy> any objection to this way forward?
<fremy> RESOLVED: cbiesinger will document chrome's behavior and we will revisit

[tabatkins]

We've reverted the change to make everything compute to 'auto' in 45d4464. 'auto', specifically, invokes too much additional magic, which was causing some issues, as cited by @cbiesinger.

Leaving the issue open to:

1. hopefully get some info from @cbiesinger as he promised ^_^
2. spend time in a few weeks to deal with [css-sizing] need to be clear about inputs to computation of min-content, max-content, and fit-content sizes #2890 in a systematic fashion.

[Loirooriol]

@tabatkins Not sure if I'm missing something, but your commit just changed "behaves as the property’s initial value" (i.e. auto) to "compute to auto". So it's basically the same, but messing with inheritance, against the resolution from #2708?

[tabatkins]

...huh, that's not what I meant. Must have copypasted a little too blindly. @fantasai and I will revisit this, sorry about that.

[janosh]

This redefinition causes unexpected and differing behavior (compared to Chrome and Safari) when combined with position: sticky; as explained here.

[Loirooriol]

...huh, that's not what I meant. Must have copypasted a little too blindly. @fantasai and I will revisit this, sorry about that.

@tabatkins ping ^

[Loirooriol]

So just to see if I understand 64d0860, if I have

#grid {
  display: grid;
  block-size: min-content;
  grid-template-rows: minmax(50px, 100px);
}

then the height should be 50px and not 100px? Chromium used to behave like this, but changed in https://crbug.com/906039

Also, now the spec says "unless otherwise specified, this is equivalent to its automatic size", not "behaves as the property’s initial value". Does this mean that in

#grid-item {
  display: block;
  min-block-size: min-content;
  block-size: 0;
}

the item is supposed to behave like block-size: auto instead of using an automatic minimum size (that would be 0)? Chromium also used to do this, but changed in https://crbug.com/902863

[css-meeting-bot]

The CSS Working Group just discussed Why was min-content etc. to be redefined to be nothing like Block axis?.

The full IRC log of that discussion

<fantasai> Topic: Why was min-content etc. to be redefined to be nothing like Block axis?
<Rossen__> github:https://github.com//issues/3973
<fantasai> cbiesinger: Seems to be disagreement between me and dbaron
<fantasai> cbiesinger: For a long time min-content/max-content/fit-content were defiend to work in the block axis
<fantasai> cbiesinger: to be the size the item would have if it weren't explicitly sized
<fantasai> dbaron: Size at what width?
<fantasai> cbiesinger: I know that's your objection to this
<fantasai> cbiesinger: Chrome had implemented this
<fantasai> cbiesinger: This is also essentially the same size that Flexbox uses for min-height: auto
<fantasai> cbiesinger: At one point spec was changed to say that block axis just computes to auto, and Chrome removed it
<fantasai> cbiesinger: However I think this is a useful thing to have
<fantasai> cbiesinger: Intrinsic size in the block axis at the specified width
<fantasai> cbiesinger: I would like to have that feature back
<fantasai> cbiesinger: discuss.
<fantasai> dbaron: You said Chrome implemented it. I'd like to see the definition of what Chrome implemented
<fantasai> TabAtkins: In particular our resolution was for you to tell us what you did so we can look at it :)
<TabAtkins> "Leaving the issue open to: hopefully get some info from @cbiesinger as he promised ^_^"
<fantasai> cbiesinger: Can write it up, but should I talk about it? or write it?
<fantasai> dbaron: I think there are a bunch of gaps in the specs, want to know how you would fill in the gaps
<heycam> fantasai: in the block axis, by saying it becomes auto, we're saying it becomes the max-content size
<heycam> ... the max content size, min content size, and auto size, are exactly the same
<heycam> cbiesinger: it doesn't work for min/max-height this doesnt work right now
<heycam> fantasai: and in that case, defining them to be teh same in the spe cdoesn't cause any problems
<heycam> dbaron: except the auto height of the block is a concept at layout time after you know the width
<heycam> ... whereas min/max content heights dont have a width to use
<heycam> ... and min/max content are referecned all over these other specs without saying it's at a particular width
<heycam> ... a particular block has a unique min content height
<heycam> ... if min-content and max-content are a function of width, then every spec that needs to use those concepts need to say what the width input is
<heycam> fantasai: I'm pretty sure grid does
<heycam> dbaron: pretty sure most specs don't
<heycam> fantasai: for block, you always have a iwdth
<heycam> dbaron: you have many widths. available width?
<heycam> ... intrinsic size of an orthogonal float...
<heycam> fantasai: that's defined in Wriitng Modes
<heycam> ... WMs says if you need the width you use viewport size plus some other calculations
<heycam> dbaron: does it say that for intrinsic size? i think it says to do that for layout, but these are different concepts
<heycam> fantasai: so you want to WMs to clarify to use it for both?
<heycam> cbiesinger: you could say it uses the width in the current layout mode
<heycam> dbaron: it's hard for me to argue this witout preparation, but the last time I went through the specs following spec links I couldn't find out how it was defined
<heycam> cbiesinger: I don't disagree
<heycam> fantasai: one thing that we are losing by defining everything ot be auto, if min/max content and auto size in block axis were always equal, it wouldn't matter
<heycam> ... but the problem is that in grid and flex, they have different emanings
<heycam> ... you get a different size, content lays out differently, in the block axis
<heycam> ... and being able to request those sizes and being able to use them within the context of other nested layouts is useful
<heycam> dbaron: but the spec right now pretends these are generic concepts across all layout systems, and not dervied from widths
<heycam> ... but layout systems define these all over without saying what width to use
<heycam> dbaron: cbiesinger and I agree that tihis is not currently defined in specs
<heycam> cbiesinger: are you objecting to the concept of this? or just the fact that this is currently not well defined
<heycam> Rossen: let's doubel down on the previous resolution
<heycam> dbaron: I think it's a huge arthicetctureal change for our layout code
<heycam> dbaron: I want it to be important and clearly defined before doing that
<heycam> dbaron: I think this is one of those things where you can get pretty close with a bunch of hacks, but that's not the same as following the spec
<heycam> ... and I still don't know what the spec is
<heycam> fantasai: you need to do some intrinsic sizing in the wrong axis to get grid/table to worth with orthogonal flows
<heycam> ... I think the architectural changes is whether you do this or not, and you already have to do it
<heycam> dbaron: right now in code hte functions that compute intrinsci size don't take a width argument
<heycam> ... and if these things are a function of width we need to work out what width to use for every caller
<heycam> ... some of this is complicated because intrinsic size is recursive
<heycam> ... it depends on all its descendants
<heycam> ... in some of these non-recurisve cases it could depend on layout, but we need to say what these cases are
<heycam> ... but I think there are cases where there are hundreds of calls to intrinsic size calculations across our code, we need to work out what to pass in
<fantasai> i/fantasai: in the block axis, by saying/ScribeNick: heycam/
<heycam> Rossen: I agree this is a large change if you are computing intrinsci size wihtout doing layout
<heycam> ... might be best to close this until we have details
<heycam> s/close this/close the discussion today/
<heycam> ... Christian has the action to write this up
<fantasai> ScribeNick: fantasai

[cbiesinger]

I believe I'm to write up Chrome's behavior (before we removed it), not write a full spec. so here it is--

We treat this very similar to height: auto -- at the end of layout, we store the height that the box ended up with before clamping it according to height/min-height/max-height. There is no need (and really, no way) to calculate this in a separate pass because never need this value outside of layout.

For orthogonal flows, we basically treat this like height: auto again. In the typical case they need to be laid out to find their width; so this fits in well with that.

The only downside is that percentages do resolve to the value they have during layout. This isn't a problem in practice. (Come to think of it, maybe the spec requires us to always resolve percentages relative to height: min-content as auto... not sure). The only place that does require special handling is flex (and, I assume, grid) due to the multi-pass layout that shrink an object -- you don't want a height: 100% child prevent flex-shrinking. So for this case, when we do the initial pass to resolve flex-basis: auto and min-height: auto, we set a flag to treat percentages as auto, which will get fixed up during the flexing pass.

[cbiesinger]

This issue also makes it harder for Blink to implement the correct min-block-size: auto behavior for aspect-ratio.

[tabatkins]

@cbiesinger As far as we can tell, the current state of the specs accurately captures what you're saying here. min/max-content resolves to the min/max-content size, as defined by the layout mode; by default, we say that this is equal to the automatic size in the block axis, but allow layout modes to override that (https://drafts.csswg.org/css-sizing/#valdef-width-min-content). Grid and Flexbox both explicitly override that by defining exactly what the min/max-content sizes are in both axises, in dedicated sections of their specs (https://drafts.csswg.org/css-grid/#intrinsic-sizes and https://drafts.csswg.org/css-flexbox/#intrinsic-sizes).

Is there anything missing there, or mis-defined such that your preferred behavior isn't allowed? If it looks good, maybe we can ask the WG to sign off.

[davidsgrogan]

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1135207 in response to #3973 (comment)

[cbiesinger]

Tab -- ok, yeah, my understanding is that the current text makes this div:

<div style="height: 0px; min-height: min-content; overflow: hidden;">
XXX
</div>

be the height of the text. If that's right, I am happy.

[tabatkins]

Yup, that's correct.

[fantasai]

Agenda+ to confirm #3973 (comment)

[css-meeting-bot]

The CSS Working Group just discussed Why was min-content, etc. redefined to do nothing in the block axis, and agreed to the following:

• RESOLVED: accept edits made

The full IRC log of that discussion

<Rossen_> Topic: Why was min-content, etc. redefined to do nothing in the block axis
<fantasai> A first terrible attempt: intrinsic-size: auto | min-zero-scrollable || min-zero-percentage
<Rossen_> github: https://github.com//issues/3973
<tantek> Rossen_: cbiesinger you opened this one
<tantek> ... and you also added it to agenda+
<tantek> cbiesinger: I did?
<tantek> Rossen_: on Jan 22
<tantek> cbiesinger: oh that was a while ago lol
<fantasai> s/Rossen_: RESOLVED/RESOLVED/
<tantek> cbiesinger: why are we discussing today, wasn't it addressed by a recent edit?
<tantek> TabAtkins: yes it was
<tantek> ... making sure others are ok with the edit
<tantek> cbiesinger: I can summarize
<tantek> ... in the block axis the ..xx.. and fit-content take the same value as auto
<tantek> Rossen_: sounds reasonable
<tantek> cbiesinger: it lets you get the min height auto behavior from flexbox and grid
<tantek> ... and ... ratio in other contexts
<fantasai> at one poin the spec defined min-content/max-content/fit-content to behave the same as 'auto' in the block axis
<tantek> Rossen_: any other opinions?
<fantasai> the edits changed that to say that the min-content and max-content sizes in the block axis are as defined by the layout model, defaulting to max-content behavior
<tantek> ... or objections to accepting the edits
<fantasai> more or less
<tantek> RESOLVED: accept edits made