[css-flexbox-1][css-sizing-3] Definiteness of min-height: min-content

via #4310 ...

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

Nonetheless, although this may require an additional layout pass to re-resolve percentages in some cases, this value (like the min-content, max-content, and fit-content values defined in [CSS-SIZING-3]) does not prevent the resolution of percentage sizes within the item.

I think this parenthetical is trying to say that min-size: min-content|max-content|fit-content do not prevent the resolution of percentage sizes same as min-size: auto. But I can't find where this is specced?

(Also none of the browsers support these keywords on min-block-size. But they parse it.)

I guess the question is do we make this parenthetical reality? Or clarify that these cases are in fact indefinite?

(Also none of the browsers support these keywords on min-block-size. But they parse it.)

Could you elaborate on the lack-of-support?

I believe we (Firefox at least) treat these keywords as auto in the block axis, which is what the spec calls for:
https://drafts.csswg.org/css-sizing-3/#valdef-width-min-content

Quoting that spec-text on what these keywords mean in the block axis (using min-content as an example here):

* min-content
     [...] for a box’s block size, unless otherwise specified, this is equivalent to its automatic size.

In that spec quote, automatic size is just linked to the definition of auto here:
https://drafts.csswg.org/css-sizing-3/#valdef-width-auto

So: these keywords are specced to behave as auto in the block axis, basically.

So if you're seeing these keywords not having any special behavior in the block axis, I think that's correct :) though maybe I'm misunderstanding the issue you're seeing.

And also, I would expect these keywords to have the same definiteness guarantees as auto (at least in the block axis where they're literally equivalent... And probably also in the inline axis since sizes are typically more eagerly definite in the inline axis, I think? Though it'd probably be worth testing some inline-axis scenarios.)

So: these keywords are specced to behave as auto in the block axis, basically.

I think that is not the intent of the spec, based on #3973 (comment) and the following few comments.

Hmm, interesting. I do see in the csswg discussion quoted there:

at one poin the spec defined min-content/max-content/fit-content to behave the same as 'auto' in the block axis

So that does indeed imply that the spec changed to mean something else. I guess in the spec-text that I quoted above, "block size" is probably literally & only referencing the block-size property (e.g. height, not max-height or min-height).

I guess we have https://bugzilla.mozilla.org/show_bug.cgi?id=1672559 filed to track changing the Firefox behavior here.

I think we are supposed to honor height: min-content also, but I can't come up with a case where that matters since in the block direction min-content size == max-content size, and height: auto resolves to that same size.

Like, the outer div's used height is 50px no matter if you honor height:min-content or not:

<div style="height:auto; max-height: 50px">
  <div style="height: 100px"></div>
</div>

<div style="height:min-content; max-height: 50px">
  <div style="height: 100px"></div>
</div>

Maybe there's an orthogonal writing mode case where honoring height:max-content matters? I don't know.

<div style="height:max-content; min-height: 50px">
  <div style="writing-mode: vertical-lr;">
    <!-- some children that change max-content size of outer div? -->
  </div>
</div>

@davidsgrogan

@davidsgrogan If I understand correctly, height: min-content would matter in grid (and probably flexbox too):

<div style="display: grid; grid-template-rows: minmax(0, 100px); height: min-content; border: solid"></div>

In https://drafts.csswg.org/css-grid/#algo-grow-tracks the base size of the row is 0px, the growth limit is 100px, but we don't distribute space under a min-content constraint. So the height should become 0px. Browsers just treat it as height: auto, though.

The CSS Working Group just discussed [css-flexbox-1][css-sizing-3] Definiteness of min-height: min-content.

The full IRC log of that discussion

<dael> Topic: [css-flexbox-1][css-sizing-3] Definiteness of min-height: min-content
<dael> github: https://github.com//issues/6457
<dael> astearns: fantasai are you on?
<dael> [silence]
<dael> astearns: Anyone on the call that can take this?
<dael> TabAtkins: fantasai and I have wanted to look but haven't had a workday. We have one Friday
<dael> astearns: Added to the agenda weeks ago
<dael> TabAtkins: A bunch of comments since then.
<dael> TabAtkins: If she knew what she wanted to talk about and it's still there sure. But had a lot of comments since
<dael> dholbert: I suggest we wait

As Oriol mentioned, min-content and max-content differ in the block axis when sizing flex and grid containers, because min-content sizing doesn't distribute any free space.

The original question still remains: the spec is currently implying that the content-based sizing keywords in the min-* properties don't prevent children from resolving %s against those sizes (even though the width/height properties themselves do). This is necessary behavior for the automatic minimum size (or else percentages would usually be unresolvable), which can be content-based, so it seems like it should be fine to specify that explicitly for all the content-based sizing keywords. But given that these keywords aren't otherwise representing definite sizes, do we actually want to?

Agenda+ to bring the issue up with the WG.

@fantasai

+1 to all this reasoning; it matches with my and @fantasai's own thoughts.

So, Agenda+ to resolve that min-height:auto just has special behavior that allows child %s to still resolve, and it's not a precedent to apply to all the other content-based keywords. (Thus, we'll remove, or possibly keep-but-reverse, the note that's currently in the spec.)

@fantasai

I agree with (a), (b), (d), (e) without reservation.

I don't disagree with (c), I just don't understand its relevance.

I don't necessarily disagree with (f) either, I just want to bring up that the "one weird trick" situation mentioned above has benefits that have so far been ignored. Namely, authors would appreciate the ability to opt in to the poorer-performing but more powerful two-pass layout in block layout (i.e. I wholeheartedly agree with @fantasai's comment at #4311 (comment))

Three comments/questions:

Am I misunderstanding something, or would this indeed be a compat-conserving way to hand authors a long-desired behavior they could opt in to?
@dholbert , above you say you "worry ... that browsers would have to start doing two-pass layouts inside of blocks in order to measure content and then resolve percentages". Agree that browsers would have to do two-pass layouts. Is the 'worry' about layout speed? Or engine-implementation complexity?
Seems to me the clear answer to the CSS-comment question above is '150px'. But maybe I'm missing something.

So, to be clear, I'm NOT advocating for making min-height: min-content allow child percentages to resolve, rather I'm trying to make sure both the pros and cons are being considered. Seems like only the cons have been discussed so far.

@dholbert

I don't disagree with (c), I just don't understand its relevance.

Point (c) was intended as support for why it makes sense to keep min-height:auto in a separate category from "min-content" / "max-content", as not interfering with definiteness. The reason being: min-height:auto doesn't even require content measurement for some cases -- e.g. scrollable grid/flex items (point (c)), and children of non-grid/flex containers (point (b)).

Am I misunderstanding something, or would this indeed be a compat-conserving way to hand authors a long-desired behavior they could opt in to?

It could be, but it feels like a potentially arcane way of doing that. If we want to address that use-case, perhaps there's a more direct way to do so?

@dholbert , above you say you "worry ... that browsers would have to start doing two-pass layouts inside of blocks in order to measure content and then resolve percentages". Agree that browsers would have to do two-pass layouts. Is the 'worry' about layout speed? Or engine-implementation complexity?

I was mostly thinking about speed, yeah. But yes, also complexity to some extent -- because we would likely want & need to add optimizations and caching to avoid two-pass layouts where possible, and those would surely have tricky edge cases, and so there would be a lot of complexity and special considerations around those optimizations.

Basically, I just wanted to express that this would not be a trivial change.

Seems to me the clear answer to the CSS-comment question above is '150px'. But maybe I'm missing something.

Based on where this thread is trending, I think the answer to my css-comment-question should in fact be "content-height", not 150px. Of course, the answer depends on whether we consider .test to have a definite height or not (once we have min-height:min-content implemented to actually do what it says).

If we do consider .test's height to still be definite, then you'd be right -- the percent-height child would be 150px tall, as you say.
But if we consider .test to have an indefinite height, then I think the percent-height on the child would be treated as auto and so the child would be content-height.
And for completeness: in browsers right now, the child is just 100px tall, since we don't honor `min-height:min-content as actually doing content-measurement.

That's why I brought up those three outcomes to compare among.

So, to be clear, I'm NOT advocating for making min-height: min-content allow child percentages to resolve, rather I'm trying to make sure both the pros and cons are being considered. Seems like only the cons have been discussed so far.

I think the pros that have been mentioned here were:
(1) pro: consistency between the content-dependent sizing keywords (including auto) in the min-width/min-height properties. But as I noted in my most recent comment above, I think it in fact makes more sense to treat auto as an exception.
(2) The "pro" that you mentioned, that it would provide the "one weird trick" to trigger percentage re-resolution in content-sized containers. If we really think that this is the right ergonomic way to provide that feature, then that's worth considering, I suppose. But I think that needs some further discussion/examples to demonstrate that this is in fact a good way to provide this behavior (rather than just being a hack).

It could be, but it feels like a potentially arcane way of doing that. If we want to address that use-case, perhaps there's a more direct way to do so?

Yes, you are right, "one weird trick" is probably not the best way to address that use-case.

Seems to me the clear answer to the CSS-comment question above is '150px'. But maybe I'm missing something.

Based on where this thread is trending, I think the answer to my css-comment-question should in fact be "content-height", not 150px.

Ah, yes, you are right. I meant 150px if we went in the other direction on this issue.

Thanks for the good responses. I now get it and am in total agreement that min-height: min-content and friends should result in an indefinite height.

The CSS Working Group just discussed [css-flexbox-1][css-sizing-3] Definiteness of min-height: min-content, and agreed to the following:

RESOLVED: min-height:auto just has special behavior that allows child %s to still resolve, and it's not a precedent to apply to all the other content-based keywords. (Thus, we'll remove, or possibly keep-but-reverse, the note that's currently in the spec.)

The full IRC log of that discussion

<dael> Topic: [css-flexbox-1][css-sizing-3] Definiteness of min-height: min-content
<dael> github: https://github.com//issues/6457
<dael> TabAtkins: We resolved a few weeks ago...the discussion on the call was roughly that min-height:auto needs it special behavior but probably didn't want to extend to other content-sizing keywords
<dael> TabAtkins: Further discussion on issue went back and forth on minor details. Overall everyone agrees that's fine
<fantasai> proposal is https://github.com//issues/6457#issuecomment-917223624
<fantasai> "min-height:auto just has special behavior that allows child %s to still resolve, and it's not a precedent to apply to all the other content-based keywords. "
<dael> TabAtkins: Prop: Accept results of last discussion - all intrinsic sizing keywords besides auto make sizes indefinite for boxes
<dael> Rossen_: Everything but auto makes it indefinite?
<TabAtkins> So, Agenda+ to resolve that min-height:auto just has special behavior that allows child %s to still resolve, and it's not a precedent to apply to all the other content-based keywords. (Thus, we'll remove, or possibly keep-but-reverse, the note that's currently in the spec.)
<dael> TabAtkins: Yeah
<dael> TabAtkins: prop from issue ^
<fantasai> rationale is in dholbert's comment https://github.com//issues/6457#issuecomment-915427806
<dael> TabAtkins: content keywords make it indefinite
<Rossen_> q?
<dael> Rossen_: Reasonable. Any comments?
<fantasai> +1 from me (and dholbert obviously ;)
<dael> Rossen_: Obj?
<dholbert> +1 :D
<dael> RESOLVED: min-height:auto just has special behavior that allows child %s to still resolve, and it's not a precedent to apply to all the other content-based keywords. (Thus, we'll remove, or possibly keep-but-reverse, the note that's currently in the spec.)

[css-flexbox][css-grid] Content-based auto min doesn't cause indefini…

Okay, so I fixed up the language incidentally in response to a different issue, but just now made it slightly clearer, and ensured that Grid uses the same language.

Just need to check if there are any tests for this behavior (both auto min not causing indefiniteness, and min-content/etc causing it).

Sorry to bump this old issue with a question, but I'm wondering if browsers currently behave like the conclusion that was reached here. Maybe this is unrelated to the issue, but I am trying to use min-height: min-content (or even max-content or fit-content) and it's not working as expected. Here's a simple reproduction: https://codepen.io/benface/pen/ZEZOXre

Navigation Menu

Repository navigation

[css-flexbox-1][css-sizing-3] Definiteness of `min-height: min-content` #6457

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-flexbox-1][css-sizing-3] Definiteness of min-height: min-content #6457

Description

Activity

fantasai commented on Jul 15, 2021

dholbert commented on Aug 18, 2021

davidsgrogan commented on Aug 24, 2021

dholbert commented on Aug 26, 2021

davidsgrogan commented on Aug 26, 2021

Loirooriol commented on Aug 30, 2021

css-meeting-bot commented on Sep 1, 2021

tabatkins commented on Sep 7, 2021

fantasai commented on Sep 7, 2021

4 remaining items

tabatkins commented on Sep 10, 2021

davidsgrogan commented on Sep 29, 2021

dholbert commented on Sep 29, 2021

davidsgrogan commented on Sep 30, 2021

css-meeting-bot commented on Oct 6, 2021

tabatkins commented on Aug 18, 2022

benface commented on Mar 12, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[css-flexbox-1][css-sizing-3] Definiteness of `min-height: min-content` #6457