Re: [csswg-drafts] [css-sizing-4] How does height: stretch interact with margin collapsing with parent (#11044)

The CSS Working Group just discussed `[css-sizing-4] How does height: stretch interact with margin collapsing with parent`, and agreed to the following:

* `RESOLVED: Accept proposal`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> TabAtkins: The spec for height:stretch around for awhile. While trying to implement, we ran into some issues with its definition<br>
&lt;fantasai> TabAtkins: mainly what info it's trying to rely on and when that info would be available<br>
&lt;fantasai> TabAtkins: also consistency issues<br>
&lt;fantasai> TabAtkins: big problem is that the rules as stated can result in multiple children getting different sizes based on where they are in the element<br>
&lt;fantasai> TabAtkins: or a single element changing size depending on presence of other elements<br>
&lt;fantasai> TabAtkins: means that mutating DOM can change expectations for what height should be<br>
&lt;fantasai> TabAtkins: after working through implications, settled on proposal that addresses the core use cases but simplifies inputs to stable<br>
&lt;fantasai> TabAtkins: height:stretch always fills parent's content box, taking into account child's own mbp<br>
&lt;fantasai> TabAtkins: if parent settings would prevent collapsing, we assume no collapsing; otherwise assume collapsing<br>
&lt;fantasai> TabAtkins: same thing for bottom margin<br>
&lt;fantasai> TabAtkins: in most cases this will do what you want<br>
&lt;fantasai> TabAtkins: if parent has border, child will fit exactly inside considering its own margins<br>
&lt;fantasai> TabAtkins: if no border, chid will fit exactly inside ignoring its own margins<br>
&lt;fantasai> TabAtkins: If you're doing this for multiple elements, all stretched elements will be the same size<br>
&lt;fantasai> TabAtkins: There are a few cases where this will cause item to be a little too large<br>
&lt;fantasai> TabAtkins: e.g. assumptions about collapsing were wrong<br>
&lt;fantasai> TabAtkins: e.g. sibling prevents collapsing<br>
&lt;fantasai> TabAtkins: but at that point you're violating the base contract of this feature, which is that you're the only thing in the parent<br>
&lt;fantasai> TabAtkins: other cases you get the sizing you expect<br>
&lt;TabAtkins> fantasai: the intention we were going with is tha tyou just pretend the item is the only thing in the box and do something simple about margin collapse<br>
&lt;TabAtkins> fantasai: in particular, a fixed height on the parent would normally prevent margin collapse but would truncate the margin; we didn't want that to cause non-collapse behavior for calculating the child's size<br>
&lt;TabAtkins> fantasai: i think Tab's proposal is basically a more correct version of what the spec is tryign to do<br>
&lt;fantasai> astearns: No compat concerns?<br>
&lt;fantasai> TabAtkins: no public implementations yet<br>
&lt;fantasai> iank_: for stretch keyword, no one has shipped yet<br>
&lt;fantasai> iank_: Blink will ship this with stretch, and then try to make -webkit-fill-available match it as a separate step<br>
&lt;fantasai> iank_: I don't think we'll run into issues due to current non-interop<br>
&lt;fantasai> astearns: proposed to adopt Tab's proposal<br>
&lt;fantasai> RESOLVED: Accept proposal<br>
</details>


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


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

Received on Wednesday, 19 February 2025 16:35:03 UTC