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

So this would mean that, if you were height:stretch and had margins, *and* you happened to be adjoining to your parent's top margin, you'd size as if you *weren't* adjoining but you actually would margin-collapse, leaving double space at the bottom of your parent? That seems not great.

The use-case for `stretch` was explicitly "do the right thing when you're the only (in-flow) child", essentially giving you inverse behavior of an auto-sized parent. (Rather than the parent sizing to you, and possibly collapsing your margins thru, you'd size to your parent, and then possibly collapse your margins thru).  The behavior for when you weren't the only child was less important and explicitly not considered  beyond making sure it was well-defined; what we were worried about was making it easy for a single element to fill an explicitly-sized wrapper.

Here, you're inverting that prioritization, favoring making sure the behavior when there are potentially multiple stretched children as good as possible, even if that results in worse behavior for the single-child case. (In particular, it means that the children will all size as if their margins don't collapse, even if they do end up collapsing.)

*If* we were going to do that, the `stretch` keyword should *also* suppress margin collapse with an element's parent, so the behavior makes sense.

But I'm still not sure we should do that in the first place. The [three-children case](https://github.com/w3c/csswg-drafts/issues/11044#issuecomment-2518616089) you outlined above just wasn't the thing we were trying to solve.

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


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

Received on Tuesday, 10 December 2024 23:09:39 UTC