Re: [csswg-drafts] [css-flexbox] overflow clip on SVG elements and flex layout (#7714)

The CSS Working Group just discussed `overflow clip on SVG elements and flex layout`, and agreed to the following:

* ``RESOLVED: in the UA style sheet, we keep `svg { overflow: hidden; }` ``
* `RESOLVED: in the flex spec, for auto min sizing, instead of saying scroll container, we read the computed overflow property value`
* `RESOLVED: overflow:hidden on replaced elements gets coerced to overflow:clip at paint time`

<details><summary>The full IRC log of that discussion</summary>
&lt;heycam> Topic: overflow clip on SVG elements and flex layout<br>
&lt;heycam> github: https://github.com/w3c/csswg-drafts/issues/7714<br>
&lt;heycam> khush: this concerns how the min width / min-height auto is computed for a flex child<br>
&lt;heycam> ... spec says that if an element is a scroll container, the min-width/height will be 0<br>
&lt;heycam> ... but if not a scroll container, then it's content based min size<br>
&lt;heycam> ... the two cases where it's not a scroll container, is if overflow is clip/hidden<br>
&lt;heycam> ... previous change made replaced elements [...]<br>
&lt;heycam> ... SVG has for a long time had `overflow: hidden` in the UA style sheet<br>
&lt;heycam> ... now we're setting overflow:clip, it causes this layout behavior<br>
&lt;heycam> ... before, min-width/height would be 0<br>
&lt;heycam> ... but now it's computing to the content based min size<br>
&lt;heycam> Ian: we got many bugs<br>
&lt;heycam> khush: fun part is that was accidentally rolled out to stable channel<br>
&lt;heycam> ... have to keep this behavior for compat<br>
&lt;heycam> ... options are to first add min-width/height:0 to the UA style sheet, which when combined with overlfow:clip gives you the preivous behavior<br>
&lt;heycam> ... but now we have different compat problems<br>
&lt;heycam> ... second option is to special case it<br>
&lt;heycam> ... either in the layout computation spot. clip behaves this way except for SVG<br>
&lt;heycam> ... other option is that we don't set the overflow:clip in the UA style sheet only for SVG, and at layout time the previous behavior continues to apply, but at paint time we use it as if it's clip<br>
&lt;heycam> ... it'd have to be a used value time thing<br>
&lt;emilio> q+<br>
&lt;heycam> ... used value would be different in paint time<br>
&lt;heycam> fantasai: maybe should've gone over #7144 first<br>
&lt;heycam> dholbert: I'm fond of the third option, keeping overflow:hidden SVG. is there a reason we need to change SVG?<br>
&lt;heycam> Ian: mainly for consistency<br>
&lt;heycam> ... we didn't perceive the compat risk<br>
&lt;fantasai> +1 to keeping overflow:hidden on svg<br>
&lt;heycam> ... only weird quirk is that at layout time, when we're looking at overflow, pretend overflow means clip at paint time<br>
&lt;heycam> ... at paint time<br>
&lt;heycam> s/layout time/paint time/<br>
&lt;heycam> dholbert: where is that used value magic? already exists?<br>
&lt;heycam> ... seems orthogonal to this<br>
&lt;heycam> fantasai: maybe we should switch to 7144<br>
&lt;Rossen_> ack emilio<br>
&lt;heycam> emilio: I have a question. overflow:clip by default on SVG, it changes the sizing behavior<br>
&lt;heycam> Ian: so min-content sizes<br>
&lt;heycam> ... auto min size will be 0<br>
&lt;heycam> emilio: if I load the test case in the first comment, and set overflow:clip/hidden, I don't see any layout change<br>
&lt;heycam> khush: flex layout was implemented first, so where it's supposed to check is this a scroll container or not, it looks at overflow value<br>
&lt;heycam> ... assumes it's not a scroll container only if overlfow:visible, but we are also now checking for clip<br>
&lt;heycam> ... this is a change in the process of landing<br>
&lt;heycam> emilio: right now SVG is not a scroll container<br>
&lt;heycam> Ian: but it does have overflow:hidden<br>
&lt;heycam> emilio: right now that decision is based on scrollable overflow<br>
&lt;heycam> Ian: computed overflow property value<br>
&lt;heycam> emilio: and you are changing that?<br>
&lt;heycam> ... but you want SVG to keep behaving the same way?<br>
&lt;heycam> Ian: the flexbox auto min size thing likely needs to say look at the computed value of overflow, rather than "scroll container"<br>
&lt;heycam> ... could make that narrower<br>
&lt;heycam> ... it becomes a used value, after layout thing<br>
&lt;heycam> emilio: I'm still confused<br>
&lt;heycam> ... I see a different if I set overflow:visible on the SVG, but not if I set overflow:clip<br>
&lt;heycam> Ian: we currently don't support overflow:clip<br>
&lt;heycam> dholbert: in Firefox I see a difference<br>
&lt;heycam> Ian: but that's not the compat concern<br>
&lt;dholbert> (If I add `overflow:clip` to https://github.com/w3c/csswg-drafts/issues/7714#issue-1366802020 , then the green thing gets wider)<br>
&lt;heycam> ... overflow visible/clip should behave the same<br>
&lt;heycam> ... but we changed the UA style sheet from hidden to clip, and that broke things<br>
&lt;heycam> emilio: maybe not change the UA style sheet?<br>
&lt;heycam> ... since it doesn't create a scroll container either<br>
&lt;heycam> Ian: at layout time you use the computed value of overflow, like we do right now<br>
&lt;heycam> ... to determine if we apply the auto min size<br>
&lt;heycam> ... and at paint time, we convert this to a used value of overflow:cip<br>
&lt;heycam> emilio: but that's basically what happens now?<br>
&lt;heycam> Ian: differences are overflow clip margin will start to apply<br>
&lt;heycam> khush: in terms of the changes in the UA sheet, we can skip setting overflow:clip, but we still need the overflow clip margin box for it to work with these elements<br>
&lt;heycam> khush: overflow-clip: margin-box<br>
&lt;heycam> ... so we'll skip setting overflow:clip, leave it as hidden<br>
&lt;heycam> emilio: proposed solution only changes the UA sheet?<br>
&lt;heycam> emilio: do we need to add magic to make overflow:hidden to behave like overflow:clip for SVG, rather than letting authors do it?<br>
&lt;heycam> Ian: we had a resolution that overflow:hidden would behave as overflow:clip<br>
&lt;heycam> ... it basically behaves like that anyway<br>
&lt;heycam> ... this is harmonizing<br>
&lt;heycam> emilio: bit unfortunatey<br>
&lt;heycam> s/unfortunatey/unfortunate/<br>
&lt;heycam> Ian: the coercion would apply to all the replaced elements, not just SVG<br>
&lt;heycam> ... if they're overflow:hidden<br>
&lt;heycam> emilio: as long as you're a replaced element<br>
&lt;heycam> ... you don't get weird cases where there's only clip on one axis<br>
&lt;heycam> ... as long as this is well tested<br>
&lt;heycam> khush: I promise!<br>
&lt;heycam> dholbert: the thing where you check the computed value for flex layout purposes, I think that already matches what we already do internally, and it's what the spec used to say<br>
&lt;heycam> ... it results to 0 if overflow is hidden/scroll/auto<br>
&lt;heycam> ... but the spec now says scroll container<br>
&lt;heycam> ... so we might want to consider reverting that, and explicitly defer to computed overflow value<br>
&lt;heycam> Ian: I think I'd prefer that<br>
&lt;heycam> ... in summary, part 1: in the UA style sheet, we keep `svg { overflow: hidden; }`. part 2: in the flex spec, for auto min sizing, instead of saying scroll container, we read the computed overflow property value<br>
&lt;heycam> ... part 3: which may already be specced, is overflow:hidden on replaced elements gets coerced to overflow:clip at paint time<br>
&lt;heycam> dholbert: you can't do scrollTop on an &lt;img><br>
&lt;heycam> khush: part 3 was resolved in #7144<br>
&lt;fantasai> +1<br>
&lt;heycam> khush: one other thing, for SVG, we're still keeping overflow-clip-margin in the UA sheet<br>
&lt;heycam> RESOLVED: in the UA style sheet, we keep `svg { overflow: hidden; }`<br>
&lt;heycam> RESOLVED: in the flex spec, for auto min sizing, instead of saying scroll container, we read the computed overflow property value<br>
&lt;heycam> RESOLVED: overflow:hidden on replaced elements gets coerced to overflow:clip at paint time<br>
&lt;heycam> &lt;br dur="13m"><br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7714#issuecomment-1248761712 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 15 September 2022 23:47:28 UTC