- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 Nov 2024 18:54:41 +0000
- To: public-css-archive@w3.org
Based on some private discussion with @davidsgrogan, a few clarifications that I think need to make it into the spec: * "adjoining as per normal" includes when it has following siblings but they're capable of being "collapsed thru". This is the cases @Loirooriol is talking about in [their earlier comment](https://github.com/w3c/csswg-drafts/issues/11044#issuecomment-2445527834). I think we can safely define that away - what we want "adjoining" to mean here is "has no preceding/following in-flow sibling nodes, except possibly collapsed whitespace text nodes". This probably means, then, that we have to manually inline our definition of "adjoining" rather than reusing the existing one. * When a BFC child has a preceding float sibling, whether it contacts the top edge of its parent or not depends on its width (if it's narrow enough to fit next to the float). This causes similar issues as the prior. Again, I think we can just take the simple case as canon and say that preceding floats prevent it from being adjoining to the top edge, for this purpose, in all cases. (Following floats would also do so.) The point of both of these is that our *intention* is just to allow an element to stretch to fill its parent in the simple, common case. We allow for reasonable complications (like the presence of abspos siblings not interfering with it), but it's fine for more complicated cases to just not work. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11044#issuecomment-2486500277 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 November 2024 18:54:41 UTC