Repository navigation
[css-sizing-3] Why was min-content, etc. redefined to do nothing in the block axis? #3973
Description
Activity
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-contentRelated: #3684
Do you have a link to the old definition?
@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
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.)
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
- added a commit that references this issue
on Jul 25, 2019 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:
- hopefully get some info from @cbiesinger as he promised ^_^
- 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.
@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 toauto". So it's basically the same, but messing with inheritance, against the resolution from #2708?19 remaining items
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
Reacted by Janosh Riebesell- added a commit that references this issue
on Mar 15, 2021 - added a commit that references this issue
on Mar 15, 2021 - added 3 commits that reference this issue
on Mar 15, 2021 - added a commit that references this issue
on Mar 16, 2021 - added a commit that references this issue
on Sep 16, 2025
https://drafts.csswg.org/css-sizing-3/#sizing-values
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)