- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Jul 2024 16:25:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Containment`, and agreed to the following: * `RESOLVED: container-type does not force layout containment, but does force an independent formatting context` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Containment<br> <fantasai> github: https://wiki.csswg.org/planning/tpac-2024#proposed-covid-protocols<br> <fantasai> iank_: When we did CQ, we split containment into layout and size containment<br> <fantasai> iank_: inline-size and block-size also<br> <dbaron> github: https://github.com/w3c/csswg-drafts/issues/10544<br> <fantasai> iank_: We've been running into issues because of enforcing layout containment<br> <florian> q+<br> <fantasai> iank_: when you CQ, you can't baseline-align, you can't allow abspos/fixedbpos to escape, scrollable overflow is broken, etc.<br> <fantasai> iank_: side-effects are annoying for developers<br> <fantasai> iank_: After investigation, the only restriction we really need is that it establishes a new formatting context<br> <fantasai> iank_: Lots of issues where devs ask us to remove these restrictions<br> <fantasai> iank_: a few paths forward<br> <emilio> q+<br> <fantasai> iank_: most ideal one, which contains the most compat risk -- but we're fine trying that, roll out behind a flag and work with devs to fix sites -- is to change container type to not enforce layout conainment, just size containment<br> <fantasai> iank_: and also establish a new formatting context<br> <fantasai> iank_: that's my ideal proposal<br> <fantasai> iank_: There are a couple other variants possible<br> <fantasai> iank_: miriam would also like to take this variant<br> <Rossen2> ack florian<br> <fantasai> florian: I'm unsure. I understand the desire to relax these constraints<br> <fantasai> florian: but not convinced about necessity<br> <fantasai> florian: e.g. abspos, if you allow to escape, then at a higher level in the tree they could cause scrollbars<br> <fantasai> florian: which then change the layout space you have to lay out in<br> <fantasai> florian: which changes the width you're querying against<br> <fantasai> florian: so it's annoying, but the constraint was there to break the circularity<br> <fantasai> florian: so yes, annoying, but are they necessary? and otherwise how do you cope?<br> <fantasai> iank_: falls under "always move forward" constraint<br> <fantasai> iank_: if you set up container, then can cause relayout<br> <fantasai> iank_: principle is moving forward -- so you add scrollbars, and don't remove them<br> <Rossen2> ack emilio<br> <fantasai> emilio: was going to bring up similar concerns<br> <fantasai> emilio: last time I checked, browsers still somewhat inconsistent wrt circularities<br> <fantasai> emilio: has that changed?<br> <fantasai> emilio: not opposed to removing, but...<br> <fantasai> emilio: for all browsers it's straighforward to do *something*<br> <fantasai> emilio: we break cycles similarly to webkit<br> <fantasai> iank_: I don't think you or webkit are following the spec<br> <fantasai> emilio: for us it would be a bigger change, because circular case would become a lot more common<br> <fantasai> iank_: block-size circularity is pretty common, actually<br> <fantasai> iank_: and I would like to fix this for web developers. It's the #1 complaint we receive for container queries<br> <florian> q?<br> <fantasai> emilio: they should complain to the WG<br> <florian> q+<br> <fantasai> iank_: they have been<br> <Rossen2> ack florian<br> <fantasai> florian: "always move forward" approach, you're saying FF and WK don't follow it well? How well is specified?<br> <fantasai> florian: Are we sure that we can gain interop on this approach?<br> <fantasai> florian: if so, then that's a path forward<br> <fantasai> florian: but if unproven, then maybe it's premature to resolve this issue<br> <fantasai> florian: maybe need to make sure "always move forward" is web-compatible<br> <fantasai> iank_: We do it today, so definitely web-compatible<br> <fantasai> iank_: FF and WK fail some tests because not doing it correctly<br> <fantasai> iank_: it comes down to interleaving style and layout, and I think we're the only ones doing it correctly today<br> <fantasai> florian: is it well-defined enough?<br> <fantasai> iank_: I also don't want to stall on this issue, because compat closes<br> <emilio> +1<br> <Rossen2> ack fantasai<br> <fantasai> fantasai: Can't speak for webkit officially because haven't discussed internally<br> <emilio> fantasai: can't speak for webkit, but in principle we want to support authors making their use cases work<br> <emilio> ah<br> <fantasai> fantasai: Some concerns about style/layout interleaving being underspecified -- I know Tab was handwaving at it in anchorpos spec<br> <fantasai> fantasai: would be good to get that specced thorougly<br> <fantasai> fantasai: but I think we should support Chrome experimenting to see how far we can push this in the direction that authors expect<br> <fantasai> iank_: [proposal]<br> <fantasai> iank_: Option 1 is introducing a new containment type, and then we have to define what that does<br> <fantasai> iank_: This option bypasses it<br> <iank_> proposed resolution: container-type does not force layout containment, but does force an independent formatting context.<br> <florian> i/[proposal]/florian: Not exactly sure what the difference in practice is between option 1 and 2, but seems fine.<br> <fantasai> RESOLVED: container-type does not force layout containment, but does force an independent formatting context<br> <Rossen2> fantasai: asking TabAtkins and iank_ to work on this independently and bring it back to the WG for review<br> <TabAtkins> Yeah happy to get an edit into the spec and ask for review<br> <fantasai> s/this independently/defining style+layout interleaving more thoroughly/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10544#issuecomment-2248438355 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 July 2024 16:25:55 UTC