- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Oct 2022 16:40:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow][css-contain][css-sizing] overflow: auto incompatible with size containment and container queries`, and agreed to the following: * `RESOLVED: for overflow:auto and size containment, 1st phase sizes without scrollbars, 2nd pass adding scrollbars doesn't change the size (b/c it is fixed). Clarify` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: [css-overflow][css-contain][css-sizing] overflow: auto incompatible with size containment and container queries<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7875<br> <fantasai> oriol: When have overflow auto, only scrollbars when overflowing<br> <fantasai> oriol: but that can affect sizing<br> <fantasai> oriol: According to spec, there are 2 ways of handling these<br> <fantasai> oriol: one behavior, if element is intrinsically sized<br> <fantasai> oriol: then inner size of element will be intrinsic size, and scrollbar added onto that<br> <fantasai> oriol: this makes the element bigger<br> <fantasai> oriol: other behavior is when element is extrinsically sized<br> <fantasai> oriol: inner size is reduced to make room for scrollbar without affecitng outer size<br> <fantasai> oriol: Blink has implemented<br> <fantasai> oriol: firefox and webkit only do this in inline axis<br> <fantasai> oriol: Having said this, behavior is problematic in different ways related to containment<br> <fantasai> oriol: examples in the issue<br> <fantasai> oriol: There's an optimization that browsers can apply<br> <fantasai> oriol: when descednant changes size, we don't have to compute size of size-contained element and its ancestors<br> <florian> q+<br> <fantasai> oriol: but if this element has overflow:auto and intrinsically sized, then adding the scrollbar can cause the outer size to grow<br> <fantasai> oriol: so we cannot apply this optimization<br> <fantasai> oriol: and then browsers are broken because they assume they can apply the optimization, and it looks bad<br> <astearns> ack florian<br> <fantasai> oriol: can get scrollbars floating outside the element, or have sudden changes in size ...<br> <fantasai> florian: I think they're broken, but for a different reason<br> <fantasai> florian: i think spec is correct<br> <fantasai> florian: because contain:size is defined to work in 2 phases<br> <fantasai> florian: in the first phase, you size as if empty<br> <fantasai> florian: not going to get scrollbars<br> <fantasai> florian: but then you fix that size<br> <fantasai> florian: then you're no longer intrinsically sizing<br> <fantasai> florian: so when you're adding content into the fixed size, you are no longer intrinsically sized<br> <fantasai> florian: at that point, you need ot add the scrollbars inside<br> <iank_> i agree with florian<br> <fantasai> florian: I think that's the bug in the implementations<br> <fantasai> florian: so Chrome is putting the bottom scrollbar outside, as if intrinsically sizign, but we're not<br> <fantasai> oriol: I guess this argument would apply even without size containment, in the normal case you have 'width: max-content' then you could say the same<br> <fantasai> oriol: during first phase you do intrinsic size, and then element gets is size computed, and then you do final sizing<br> <vmpstr> fantasai: is the example with max-content with or without size containment? if it doesn't have it, we don't fix the size so we get weird results with scrollbars if you have normal element with normal sizing<br> <iank_> q+<br> <fantasai> oriol: In grid layout, if grid container has width:max-content, then first you run track sizing algo with indefinite size<br> <fantasai> oriol: and then when you know this size you fix the grid container and lay out again<br> <fantasai> oriol: regardless of size containment or not<br> <fantasai> oriol: so maybe the behavior of scrollbars added on top, reduce the inner size, maybe this wording may need to be different or maybe I didn't explain it well<br> <fantasai> oriol: but the same argument would apply in both contained an non-contained one<br> <astearns> ack iank_<br> <fantasai> iank_: I think this is two problem<br> <fantasai> iank_: I agree with florian, initialy size it without scrollbars present and then it will overlay content if you overflow in that direction<br> <fantasai> iank_: I think that's straightforward, should get a resolution<br> <fantasai> iank_: more general problem of sizing things in the presence of auto scrollbars<br> <fantasai> iank_: is complicated<br> <fantasai> iank_: we have our layout engine a little state machine that will go through and basically add scrollbars [missed]<br> <fantasai> iank_: still bugs trying to get rid of<br> <fantasai> iank_: but that's a separate issue<br> <fantasai> florian: might be complications in various layout modes, I think for contain case the spec is clear<br> <fantasai> florian: about the 2 phases<br> <fantasai> oriol: so final outer size does not depend on whether it gets scrollbars or not?<br> <fantasai> florian: correct<br> <fantasai> oriol: then we have circularity problem with Container Queries<br> <fantasai> astearns: If you want to present an additional problem, that should be in the issue or separate issue<br> <fantasai> astearns: we do need to get to next item<br> <fantasai> [discussion of resolution to take]<br> <fantasai> florian: I think the spec specifies this correctly<br> <fantasai> florian: could be clearer, but it's there<br> <fantasai> oriol: I think it needs to be clarified with interaction with spec prose in css-overflow<br> <fantasai> oriol: Because overflow says to recalculate sizes<br> <fantasai> astearns: so one proposal is to clarify that when things are initially sized under size containment, they're sized without scrollbars<br> <fantasai> florian: that's clear<br> <fantasai> florian: it's the other part that's less clear<br> <fantasai> florian: once you add the content, size containment says you keep the size fixed<br> <fantasai> florian: and just because you have scrollbars, doesn't change that fact<br> <iank_> i'm fine with that.<br> <fantasai> astearns: Proposal is to clarify that in 1st phase size without scrollbars, and in 2nd pass scrollbars don't change the size<br> <fantasai> RESOLVED: for overflow:auto and size containment, 1st phase sizes without scrollbars, 2nd pass adding scrollbars doesn't change the size (b/c it is fixed). Clarify<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7875#issuecomment-1284291565 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 October 2022 16:40:21 UTC