Re: [csswg-drafts] [css-flexbox-1][css-sizing-3] Definiteness of `min-height: min-content` (#6457)

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

> 1. 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?

> 2. @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.
 
>     3. 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](https://github.com/w3c/csswg-drafts/issues/6457#issuecomment-915415947) 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 pro's 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).

-- 
GitHub Notification of comment by dholbert
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6457#issuecomment-930475319 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 29 September 2021 19:23:40 UTC