- From: Daniel Holbert via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Sep 2021 19:23:38 +0000
- To: public-css-archive@w3.org
> 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