- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 25 Feb 2026 17:54:56 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] [scoped] auto-nesting for self-participating scroller scopes`, and agreed to the following: * `RESOLVED: Add the UA stylesheet rules mentioned in this issue` <details><summary>The full IRC log of that discussion</summary> <fantasai> bramus: When you start an element-scoped view transition, you get the top video in which items inside the scroll container bleed out of the container visually<br> <fantasai> bramus: They're still contained in the overlay element, which is attached<br> <fantasai> bramus: but visual overflow<br> <fantasai> bramus: Proposal is to add something to UA stylesheet to clip that stuff<br> <fantasai> bramus: We have nested view transition groups<br> <fantasai> bramus: So we'll add 2 rules<br> <vmpstr> q+<br> <fantasai> bramus: One to contain the nesting, and the other to add a 'overflow: clip'<br> <lwarlow> +1 the second video is clearly the expected behaviour imo.<br> <fantasai> bramus: That way you get result from the second video<br> <fantasai> bramus: I've built tons of demos, and it's always the first thing I add to my CSS. So far didn't find a reason to not do it.<br> <astearns> ack vmpstr<br> <fantasai> bramus: so authors get expected behavior out of the bo<br> <fantasai> x<br> <fantasai> vmpstr: Not opposed, but issue around classic scrollbars<br> <fantasai> vmpstr: Visually this will look incorrect because content will be clipped by border-box of view-transition-group-children pseudo<br> <fantasai> vmpstr: which doesn't include the classic scrollbars<br> <fantasai> vmpstr: so content will paint over scrollbar during the transition<br> <fantasai> vmpstr: which is not quite what you want<br> <fantasai> vmpstr: I'm happy to take this resolution, but we should also fix the scrollbar gutter problem<br> <lwarlow> q+<br> <astearns> ack lwarlow<br> <bramus> q+<br> <fantasai> lwarlow: I think the second video is clearly the behavior we want. Is there an easy way to fix the classic scrollbar problem?<br> <fantasai> lwarlow: With current styles it would still paint over scrollbars, it'll just paint even more outside the box<br> <fantasai> vmpstr: I guess we did take a resolution to add the scrollbar-gutter values, but didn't talk about adding it to this pseudo.<br> <astearns> ack bramus<br> <astearns> q+<br> <fantasai> bramus: Was going to ask, with new scrollbar thing, would we need something else and this would be fixed?<br> <fantasai> bramus: or would it be unfixable?<br> <fantasai> vmpstr: I think in the long term everything will just work<br> <fantasai> vmpstr: in the short term, by default, you might not get classic scrollbars looking quite right.<br> <fantasai> vmpstr: not as bad but still a little glitchy<br> <fantasai> vmpstr: Authors can't do anything about it today, but if browser by default is doing it, then that looks like a browser bug.<br> <fantasai> vmpstr: So it's a question of who is responsible for this.<br> <fantasai> bramus: if author added the CSS, then still a browser bug...?<br> <flackr> q+<br> <fantasai> vmpstr: But at least it's not our fault it's glitchy<br> <fantasai> astearns: How does this get expressed in the UA stylesheet?<br> <lwarlow> That feels like a bit of a cop-out imo. The browser is still responsible here.<br> <fantasai> astearns: Is that something authors can easily override?<br> <fantasai> astearns: If someone discovers a good thing in the future, is it a problem?<br> <fantasai> bramus: Steve is using #A to identify the scope root. It's self-participating, gets view transition name of 'root'.<br> <fantasai> bramus: This is all CSS they can write themselves<br> <astearns> ack astearns<br> <fantasai> bramus: I still think the default behavior is that you expect stuff inside a scroll container to be contained by it<br> <fantasai> bramus: if it's not, it's pretty bad<br> <fantasai> bramus: if paints over classic scrollbars maybe that's ok<br> <fantasai> bramus: we can fix it down the road<br> <astearns> ack flackr<br> <fantasai> flackr: I think we should adopt this new behavior even if not quite right for scrollbars<br> <fantasai> flackr: because from compat perspective, fixing scrollbar is easy, whereas converting all existing view transitions will be a bigger breaking change<br> <lwarlow> +1<br> <bramus> Very good point<br> <fantasai> +1<br> <vmpstr> +1<br> <bramus> +1<br> <fantasai> flackr: I think we want to eventually get to "it works correctly" and this is the first big step we need to take<br> <fantasai> vmpstr: Can we add an issue in the spec wrt the scrollbar issue?<br> <fantasai> astearns: Sure<br> <fantasai> astearns: And take into account for scrollbar gutter<br> <fantasai> PROPOSED: Add the UA stylesheet rules mentioned in this issue<br> <lwarlow> +1<br> <fantasai> RESOLVED: Add the UA stylesheet rules mentioned in this issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13420#issuecomment-3960986695 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 February 2026 17:54:56 UTC