[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.