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

The CSS Working Group just discussed `Definiteness of min-height: min-content`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> topic: Definiteness of min-height: min-content<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/6457<br>
&lt;fantasai> “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<br>
&lt;fantasai> 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?”<br>
&lt;fantasai> TabAtkins: Original question of issue is still open<br>
&lt;fantasai> TabAtkins: for reasons of usability, we had to rule that 'min-size: auto' does not prevent percentages on your children from resolving<br>
&lt;fantasai> TabAtkins: even though technically the size of parent might be dependent on size of contents<br>
&lt;fantasai> TabAtkins: because if not, percentages would hardly ever resolve in flex or grid<br>
&lt;fantasai> TabAtkins: But we have also the min-content and max-content keywords<br>
&lt;fantasai> TabAtkins: Do we make these also not block percentage resolution on children?<br>
&lt;Rossen_> q?<br>
&lt;fantasai> TabAtkins: or do we want to hold the line, and have these content-based keywords block percentage resolution<br>
&lt;fantasai> TabAtkins: just like they do in the not-min sizing properties (width/height/etc.)<br>
&lt;fantasai> TabAtkins: Not necessarily need to resolve now, but wanted to bring up the quesiton<br>
&lt;fantasai> iank_: I'd want to discuss with David<br>
&lt;fantasai> dholbert: I think given how treated as 'auto' right now, there might be web-compat demand for them to have same definiteness properties.<br>
&lt;TabAtkins> fantasai: Given they're "treated as auto" and not commonly used, there's not much incentive for authors to use them right now, especially in a min-size property; feels unlikely that there's compat risk<br>
&lt;fantasai> Rossen_: Any concrete use cases?<br>
&lt;fantasai> TabAtkins: no, this is a question of consistency<br>
&lt;fantasai> TabAtkins: what kind of divergence do we want here<br>
&lt;fantasai> TabAtkins: we need an answer for the spec, but having use cases<br>
&lt;fantasai> dholbert: for non-definite case<br>
&lt;fantasai> dholbert: consider a deeply-nested flexbox case<br>
&lt;fantasai> dholbert: want content-based minimum<br>
&lt;fantasai> dholbert: but don't want perf complications<br>
&lt;fantasai> dholbert: so switch from auto to min-content<br>
&lt;fantasai> dholbert: That said, browser could also maybe detect the lack of percentages inside the element<br>
&lt;fantasai> dholbert: and not run the second layout pass<br>
&lt;fantasai> dholbert: Can't think of another justification for not being definite<br>
&lt;fantasai> jfkthame: agree<br>
&lt;fantasai> Rossen_: ...<br>
&lt;fantasai> Rossen_: I think the perf problem stated here is more of a speculation<br>
&lt;fantasai> Rossen_: less a concrete concern<br>
&lt;fantasai> Rossen_: my preference would be to keep it consistent<br>
&lt;fantasai> fantasai: consistency works both ways<br>
&lt;Rossen_> s/.../The deeply nested elements can be made context aware and resolve % only in the cases of having both % and min-content/<br>
&lt;fantasai> fantasai: these keywords in 'height' cause it to be indefinite<br>
&lt;fantasai> fantasai: so do we want to be consistent with that? or with 'min-height: auto'?<br>
&lt;fantasai> Rossen_: where do we go from here?<br>
&lt;fantasai> fantasai: Tab and I are happy for people to think about it. We just wanted to bring it up and explain on the cal.<br>
</details>


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


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

Received on Wednesday, 8 September 2021 16:47:08 UTC