- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 17 Jan 2025 20:01:21 +0000
- To: public-css-archive@w3.org
Okay, so @bfgeek, @davidsgrogan, and I discussed this again. After some chatter back and forth, we concluded on the following behavior: * `height: stretch` gives the child a sufficient height to fill its parent's content box. * If the parent has top border, top padding, or is an independent formatting context, take the child's top margin into account; otherwise assume it'll collapse away and treat it as zero for calculating the `stretch` height. * Mutatis mutandi for bottom margins. (Remove the text about actually resolving the child's bottom margin to 0.) And that's it. This satisfies a few of Ian's concerns (all 'stretch' children will get the same height, and adding/removing other children won't affect the stretch child's height). It ignores all other margin-collapsing complications, on the assumption that these are outside the bounds of the behavior contract. Looking at [Oriol's testcases](https://github.com/w3c/csswg-drafts/issues/11044#issuecomment-2445527834), we'd get the behavior in the first column in both cases. This does mean that you can get overflow if you assume you'll collapse with your parent, but a zero-height preceding sibling interrupts that and prevents collapse. (Oriol's first testcase, linked above). We think this is acceptable. If the interrupting sibling is *non-zero* height, then the `stretch` contract is already broken; *regardless* of how we treat margins, it'll overflow, just by varing amounts. A zero-height interruptor is an odd corner case that we shouldn't worry ourselves over. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11044#issuecomment-2599101601 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 17 January 2025 20:01:21 UTC