- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Jul 2023 21:15:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain][css-overflow] Setting containment on root should not make scrolling impossible`. <details><summary>The full IRC log of that discussion</summary> <fantasai> miriam: Decided with container queries not to have container on root<br> <fantasai> miriam: but said authors should be able to set root as container, and be able to query it similar to media queries with some advantages of it being an element<br> <fantasai> miriam: but it doesn't quite work<br> <fantasai> miriam: because if you set size/layout containment on root element<br> <florian> q+<br> <fantasai> miriam: the overflow property propagates to the viewport, but size/layout containment causes the root to not have any scrollable overflow<br> <fantasai> miriam: so we need to either say, when you set containment on root, the overflow property doesn't propagate to root and get scrollbars<br> <fantasai> miriam: or we propagate containment to the viewport<br> <fantasai> miriam: not sure if that means anything other than "it doesn't apply to the root"<br> <Rossen_> ack florian<br> <fantasai> florian: I believe the first one has a well-defined behavior that's useful<br> <fantasai> florian: One thing that makes it ok is that when we no longer propagate to viewport, the the viewport gets default value of 'overflow' which resolves to auto on the viewport<br> <emilio> q+<br> <fantasai> florian: therefore if the root itself would overflow the viewport, you get scrollbars to see all of it. It might be odd, but you can access all the content<br> <emilio> fantasai: I think that having the containment and overflow apply to the root element would be pretty terrible<br> <emilio> ... because if you do size/layout containment you get 0-height and no overflow<br> <emilio> ... if you also have paint containment you also clip<br> <emilio> ... if you compensate by making the root element larger<br> <emilio> ... then you have a scrollbar which is inside the border edge of the root element rather than to the viewport<br> <florian> q+<br> <emilio> ... which is also not great<br> <Rossen_> ack florian<br> <florian> q-<br> <Rossen_> ack fantasai<br> <emilio> fantasai: I think the first option is terrible and we should propagate containment to the viewport<br> <fantasai> miriam: you would likely uses 100% rather than 100 vh<br> <fantasai> miriam: but it's only minimally better<br> <fantasai> miriam: I agree that the other is nicer for authors<br> <fantasai> Rossen_: would that be compatible? then percentages on body would resolve (whcih wouldn't previously)<br> <Rossen_> ack emilio<br> <florian> q+<br> <dbaron> emilio: What's the difference between propagating containment to the viewport rather than just not applying containment to the root?<br> <dbaron> Scribe+<br> <fantasai> iank_: containment on root is probably pretty rare in the web<br> <dbaron> miriam: It establishes a container for querying.<br> <fantasai> iank_: remind me the syntax?<br> <fantasai> miriam: @container [...]<br> <fantasai> emilio: so the size of the root...<br> <dbaron> (I think what I scribed above goes here)<br> <fantasai> emilio: what you want isn't the root element box size, it's the viewport?<br> <fantasai> miriam: I was assuming you'd get the root size, but in general what the author would do is size the root to 100% so they can get the viewport size<br> <fantasai> miriam: the difference between that and media query is that you can use actual font sizes (for font units)<br> <fantasai> miriam: other than that you want a container that's a fallback for everything for the page<br> <fantasai> emilio: isn't the fallback already the root?<br> <fantasai> miriam: no, there is no default<br> <Rossen_> q?<br> <fantasai> miriam: we intentionally didn't, because there are cases where it would be surprising if you didn't expect it<br> <fantasai> florian: so, size containment doesn't mean size to zero. It means size as empty<br> <fantasai> florian: most typically case is querying width, so empty isn't zero<br> <fantasai> florian: it would work better than viewport, because if there are margins etc, then you are considering those<br> <fantasai> florian: in the block axis, yes, you would size the root to zero<br> <fantasai> florian: but is it that bad?<br> <emilio> q+<br> <fantasai> florian: I'm not sure the scenario is that bad as imagined<br> <Rossen_> ack florian<br> <fantasai> emilio: fallback is for container units but not container queries?<br> <Rossen_> ack emilio<br> <fantasai> emilio: that's a bit weird<br> <fantasai> miriam: yes<br> <fantasai> emilio: ignoring containment on root to make this work seems sketchy<br> <fantasai> emilio: I am a bit torn<br> <fantasai> dbaron: I'm struggling at this point to understand the ways in which ignoring containment on the root and propoagating to the viewport different<br> <fantasai> dbaron: (other than for container establishing effects)<br> <fantasai> dbaron: though I guess they differ because of the size of the root, but unsure what that means for effect on developers<br> <florian> q?<br> <florian> q+ fantasai<br> <fantasai> emilio: is alternative to this to provide an opt-in to fall back to viewport somehow?<br> <fantasai> emilio: if we didn't do the fallback because we think it's confusing.. then what makes it not confusing would be having an opt in<br> <fantasai> iank_: it's confusing if you're writing these rules and you don't expect it to resolve yet because you haven't specified a container, and then it suddenly resolves<br> <fantasai> miriam: if you're mainly using CQ on small things, and end up not being in a small thing and get a very large result<br> <fantasai> miriam: can be confusing<br> <fantasai> miriam: bu in other cases want the nearest container, and in that case want the fallback<br> <fantasai> miriam: if you added containment on root, you can add a name so that you can reference it<br> <fantasai> miriam: if you're in control you can handle both use cases, if not can only handle one<br> <Rossen_> ack fantasai<br> <emilio> fantasai: don't know what to say<br> <emilio> florian: put you on the queue about the scenario you were concerned about<br> <emilio> ... not sure what happens<br> <emilio> fantasai: containment works in both axes right?<br> <emilio> florian: not necessarily, if you only do it on one axis doesn't collapse to zero<br> <emilio> ... in the block direction if you set it to a 100% shouldn't it be fine<br> <emilio> ... if we propagated neither overflow nor containment, shouldn't it work?<br> <emilio> ... you'd set the block size to 100%<br> <emilio> fantasai: if the content needs to scroll you wouldn't be using the viewport scroller but an internal scroller<br> <emilio> ... is it the same?<br> <emilio> q+<br> <fantasai> emilio: It's not the same. There are UA features that only work on the root scroller, like marking find-inpage things, etc.<br> <fantasai> smfr: anothre difference is bakground-attachment fixed is optimized for root scrolling<br> <fantasai> Rossen_: let's take the issue back to GH and talk about it there, once we have a path for resolution we can bring it back<br> <fantasai> me github-bot, topic https://github.com/w3c/csswg-drafts/issues/3473<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9003#issuecomment-1646246626 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 July 2023 21:15:51 UTC