- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 10 Dec 2025 17:00:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] [scoped] Clarify the ::v-t box and stacking context position relative to the scope`. <details><summary>The full IRC log of that discussion</summary> <bramus> astearns: we discussed this before<br> <bramus> vmpstr: yes<br> <bramus> … discussed at TPAC and had a resolution to say that the v-t pseudo stacking context ist he parent of the scope while the object remains the child<br> <bramus> … prototyped some of it to see if ti works, some details to work out<br> <bramus> … 1 thing to do with clipping; sepcifically if the SC of the ::VT is th parent ofthe scope then teh scope wouldn clip that pseudo<br> <bramus> … also shouldnt clip it because it self-contains the representation of the border box<br> <bramus> … consequence is that any descendeant is also not cliippe dby it, which is unexepected for devs<br> <bramus> … cos they would pop out<br> <JakeA> q+<br> <bramus> … so we do want them clipped<br> <bramus> … we resolved a while ago to have nested view transitions that allows you to construct a tree that allows clipping<br> <bramus> … used the ::view-transition-group-children pseudo<br> <bramus> … we like to apply this here, specifically for scoped view transitions<br> <bramus> … the scope el would by default have a `view-transition-group: contain`<br> <bramus> … there is a lot of discussion around the fact that this property only has an effect on els with a `view-transition-name`<br> <bramus> … should we therefor emandate if the scope element needs a name, and we think we do<br> <bramus> … but authors can remove that<br> <bramus> … some options here<br> <astearns> ack JakeA<br> <bramus> JakeA: I like the idea of using groups for this<br> <bramus> … the issue suggested that they would be clipped by the parent, not the group<br> <bramus> … what ahppens if an el is transitioning from 500x500 to 10x10 … when would the 10x10 clipping apply to the children?<br> <bramus> vmpstr: this is somewhat of a tangent, bc we have not discussed what happens when the scope resized … and do believe that …<br> <bramus> bramus: it animates, no?<br> <bramus> vmpstr: with a regular VT we skip the transition if you resize the document. Same could apply with scoped transitions<br> <bramus> … it would have to instantly move along with the scoped element<br> <bramus> … be instant, and move pseudos with it<br> <bramus> JakeA: Seems reasonable … it will catch people up … no argument from me on position – its less clear to width and height but can see why … makes sense<br> <bramus> vmpstr: can raise separate issue for this<br> <bramus> … so, back to this issue:<br> <bramus> … if we assume that we do but `v-t-g: contain` on this and want the scope participatiotn to be optional, what are our optinos?<br> <bramus> … 1. the group still applies if there is no name on the scope, and it just contstructs the `::view-transition-group-children` pseudo<br> <bramus> … as bramus pointed out, that is weird because it would have no name in between the brackets<br> <bramus> … my proposal there is to use a keyword<br> <bramus> … 2. alternative option from bramus/noam is to add a new property like `view-transition-capture-mode: geometry`<br> <bramus> … whcih measn we dont catpure old state, only show new state, and forward poitner events to it<br> <bramus> … would say that `view-transition-name: root !important` in the UA stylesheet<br> <astearns> instant allergic reaction to the word 'mode'<br> <bramus> … but author can opt out from old capture by specifying this new propert<br> <bramus> … can already polyfill that by styling their own elements, but makes it more convenient<br> <bramus> … minor question now is for `view-transition-name: containt` is that we create the structure for clipping but dont clip ourselves<br> <bramus> … can leave that open for now<br> <bramus> … curious to hear about the structure<br> <bramus> astearns: bewteen the two optoins, i have an allergic reactoin to adding a mode<br> <bramus> q+<br> <bramus> … my naive prefernece would be the other<br> <astearns> ack bramus<br> <ydaniv> scribe+<br> <JakeA> The demo bramus is referencing: https://simple-vt-demos.jakearchibald.com/video/<br> <ydaniv> bramus: 1 thing I like about the 2nd option is that it also helps with request from authors is that they want to morph elements in place<br> <vmpstr> s/view-transition-name: containt/view-transition-group: contain/<br> <ydaniv> ... and they now work around it<br> <ydaniv> ... and also showing the new element immediately in VT as it is ongoing<br> <ydaniv> ... also solves this issues authors had before<br> <ydaniv> ... I discussed it with noamr about pointer events, has separate issue, and this fits in bigger picture here<br> <ydaniv> vmpstr: you want to add a new property which allows you to act as if you didn't capture the old pixels<br> <ydaniv> bramus: yeah<br> <noamr> q+<br> <ydaniv> vmpstr: and also to confirm this is fully implementable today<br> <ydaniv> ... as a perf improvement<br> <ydaniv> noamr: the hit testing thing with pointer events is not polyfillable today<br> <ydaniv> ... what this means is that the element in the pseudo tree is not a pair of snapshots, just a proxy to the element<br> <JakeA> q+<br> <ydaniv> ... instead of the pair of images we have today<br> <bramus> vmpstr: would still be stylable by authors<br> <ydaniv> vmpstr: it would still be styled by have object-view-box can change, and hit testing would do the proper mappings<br> <bramus> … hit testing would do all of the approrpiate mappings<br> <ydaniv> noamr: right<br> <astearns> ack noamr<br> <astearns> ack JakeA<br> <bramus> JakeA: im trying to separate out the two options<br> <bramus> … am I right that option 1 is that it doesnt matter if the root has a `view-tranisiton-name` and that it always get cpatured, whereas option 2 enforces it at the UA level<br> <noamr> q+<br> <bramus> … the 2nd proposal doenst have that, can still achieve with CSS<br> <bramus> vmpstr: modulo the pointer events<br> <bramus> noamr: and extra capture<br> <noamr> q-<br> <bramus> vmpstr: the difference is that in the first proposal, whethe ror not the scope has a name it still means we construct the group and group-children pseudos. IN the second we force the scope to have a name (UA Style Sheet) so it naively would have all the sturcture, but with this extra property can exclude the ::old and forward hit-testing<br> <bramus> JakeA: is the hit testing a new feature? or exist elswhere?<br> <bramus> bramus: discussed it before in august, but no resolution<br> <bramus> vmpstr: desirable effec tot have hover effects and such. if it solves this problem as well,t hen maybe its the right approach<br> <bramus> bramus: in the issue on the pointer events, I recall tim saying that this looks implementable on their end<br> <bramus> JakeA: If there are … because this is a group and there ar ethings insid wehich might show their old contant … how does the pointer forwarding happen in that case?<br> <bramus> vmpstr: there is no old content in this case<br> <bramus> … would not capture it<br> <bramus> JakeA: but you would in sid ethe group/ its only not there fo rthis 1 element ; and those children might be showing their old content<br> <bramus> … what happens if I click on one of those old ones?<br> <flackr> q+<br> <emilio> q+<br> <bramus> vmpstr: hit testing initially happens on the psueod tree. old pseudos end the journey. only when hit testing on a new, it forwards to the real eelemnt with this<br> <bramus> JakeA: So, i’ve got root with this new thing one it and it has a hover effect to change color on hover. gut there is a child element with a v-t-name and tha tis fadineg from it old to new state without this property. if my mouse is in that inner elmeent, is the hover effect happening on the parent?<br> <bramus> vmpstr: currently no<br> <bramus> JakeA: I wonder if trying to bundle complicates this … seems like a hard problem to solve …<br> <bramus> vmpstr: fwiw: neither of the options solve this<br> <bramus> … whehter you hit test via or (missed)<br> <bramus> skobes: it seems like option 2 is more complicated than 1<br> <bramus> JakeA: yes, because we have to solve all that<br> <astearns> ack flackr<br> <noamr> q+<br> <bramus> flackr: I think its prblematic that we are trying to bring in all this hit-testing stuff here, which we want to solve separately<br> <bramus> … how we forward the pointer events. dont see why this has to be part of how we capture the scope root’s clip<br> <bramus> … can set pointer=events: none on the ::view-transition and everything is fine<br> <emilio> q-<br> <bramus> … my preference would be something option 1-like<br> <emilio> +1 to flackr<br> <bramus> … dont need to be incorporating hittesting here<br> <astearns> ack noamr<br> <bramus> noamr: I tend to be ?? by this … have some tweak to optoin that could make it work really well<br> <vmpstr> s/??/convinced/<br> <bramus> … to force th ename only when capturing the new state<br> <astearns> s/??/convinced/<br> <bramus> … + having no animation when new is the only child<br> <bramus> … if the author would remove the root name from the scope you}d end up with only a new pseudo<br> <bramus> … and a UA style that doesnt animate it, so that it doesnt fade in<br> <vmpstr> q?<br> <vmpstr> q+<br> <bramus> … in essence, would have same rsult … optiont 1, but authors removing it from the old does not affect the new … we are forcing the new<br> <bramus> … if author removed root, it will be a non-animated new state<br> <astearns> ack vmpstr<br> <bramus> vmpstr: dont think tha twould more like option 1 but more like option 2<br> <bramus> noamr: yes, but would still behave like … if we fix opointer events in the other issue, then it would at least not capture only have the new pseudo<br> <bramus> vmpstr: From what Im hearing we should avoid dealing with poitner events for this issue<br> <bramus> … I think there is some details about the pointer-events … there are more implications than just hit testing … should discuss in that other issue and come to some resolution here.<br> <bramus> astearns: timecheck … halfway trhough … maybe take back to issue to have us just deal with clipping excluding pointer events for now<br> <bramus> vmpstr: other issues are far less consequential than this one<br> <bramus> …if I can make a bold suggestion, can we say that we want to suppport ht scope being optional to support interactive elements, but the solution to that should not incldue and of th eold or new pseudos. does this sound reasonable?<br> <bramus> … we want to scope participation be optional, and when it is not we dont want to be creating the old or new pseudos<br> <bramus> JakeA: what is consequenc eon pointer stuff?<br> <flackr> q+<br> <bramus> vmpstr: we avoid dealing with it<br> <bramus> q+<br> <astearns> ack flackr<br> <bramus> flackr: i think that is a resonalbe idea but dont udnerstsand how this complicates pointer events going to the scope<br> <bramus> … if you hit the pseudo, the original element is the scope, so you’d still get hover<br> <bramus> … seems to me tha tall tha tis required is to not have any pseudo that has pointer-events auto above that content<br> <bramus> … so whtahever capture we do (so no old or new) … you”ll just hit the content behind<br> <vmpstr> q?<br> <bramus> vmpstr: right<br> <ydaniv> bramus: this would still be under author control<br> <noamr> q+<br> <JakeA> q+<br> <ydaniv> ... they still want to cross fade content, but we still need some property to indicate to capture the pixels and do the regular things<br> <astearns> ack bramus<br> <emilio> q+<br> <ydaniv> ... and the thing noamr proposed also works for me, capturing something dimensions or pixels seems wierd, if you have VT-name none on something and you wouldn't force still capture that would seem wierd<br> <astearns> ack noamr<br> <bramus> noamr: wanted to say that maybe given the other work on pointer events, maybe its ok to force self-participation.<br> <bramus> … maybe the thing that we can do is use `pointer-events: none` like rob said<br> <bramus> … can force self-participation and leave thd `none` to just document vts<br> <bramus> … maybe this is not the mechanism that we should to for going forward just forward witht this<br> <JakeA> q-<br> <bramus> … aything with hit testing and optimzing capture can be done separately<br> <bramus> JakeA: sounds good<br> <astearns> ack JakeA<br> <astearns> ack emilio<br> <bramus> emilio: agree that probably tha tworks, but main issue with poitner events and the vts: one of them is scoped dont use the top layer by default so thats no issue here but for regular ones that is<br> <bramus> … if that doesnt happen here its fine<br> <vmpstr> q+<br> <bramus> … other one is that the cpatured content is supposed to behave as visibility: hidden, which does need fixing in the spec.<br> <astearns> ack vmpstr<br> <JakeA> q+<br> <bramus> vmpstr: I’m happy to say that for now we force the `view-transition-name` on the scope via the UA style sheet. that would unblock the work here. are we then ok here as well to have `view-transition-name: contain` here<br> <bramus> … if we can improve the performance later on, then we can do that later<br> <bramus> bramus: and then they can hide the old and not-animate the new to get the effect they want<br> <vmpstr> s/view-transition-name: contain/view-transition-group: contain/<br> <bramus> JakeA: yes<br> <bramus> JakeA: Remind me again for groups: is the clipping done by default?<br> <bramus> vmpstr: not by default. can say here that we do want to do that … no strong opinion<br> <bramus> bramus: didnt skobes propose to do it conditionally?<br> <bramus> skobes: yes<br> <bramus> bramus: but can resolve on that later<br> <bramus> vmpstr: want to propose to add `view-transition-name: root !important` and `view-transition-group: contain` in the UA stylesheet for scoped VTS<br> <JakeA> q+<br> <bramus> astearns: let’s state both parts<br> <noamr> proposed resolution:<br> <astearns> ack JakeA<br> <bramus> … so in a v-t scope it will have both declarations applied int he UA stylesheet?<br> <bramus> vmpstr: yes<br> <bramus> JakeA: “when this stye is applied” needs to not clash wiht a document VT<br> <bramus> vmpstr: that’s one of the next issues<br> <bramus> JakeA: I support it<br> <bramus> skobes: we do understand this breaks interactvitiy for non-participating elements until this solves the pointer events issue<br> <bramus> JakeA: seems good to solve that hollisticly<br> <bramus> flackr: dont think thats true … you can stll use pointer-events to interact with the content<br> <bramus> skobes: but you wont see it<br> <JakeA> q+<br> <bramus> flackr: in the new state speudo if you hide the old<br> <bramus> … or is this becauseof the line in the spec?<br> <JakeA> q-<br> <bramus> skobes: for doc VTs you can set v-t: none on root and pointere-events: none to regain interactivity<br> <bramus> flackr: if you hide the old and new then?<br> <bramus> bramus: then you dont see anythin<br> <bramus> flackr: if you only hide the old, then don’t they go to the orig element?<br> <bramus> JakeA: this boils down to what emilio said before, it gets treated as hidden<br> <bramus> vmpstr: which is by design<br> <bramus> flackr: can solve this generally later on<br> <bramus> astearns: skobes, are you concerned that we are lockin gourselves out for pointer events?<br> <noamr> q+<br> <emilio> q+<br> <bramus> skobes: no. my concern is that we might ship something that could be worse than the model that document transitions have enabled and that we are blocking it on a more complicated proposal<br> <bramus> JakeA: tend to agree. that authors can override to `none` but we would still capture it<br> <flackr> +q to JakeA, i think we should allow setting name to none, and still make group<br> <astearns> ack noamr<br> <bramus> noamr: current doc VT solution is kind of a half solution because it only works on the root<br> <JakeA> apologies for jumping queue<br> <bramus> … very big thing with lot of subthings. Makes me feel this probably OK.<br> <bramus> … wether we solve it here, the other problem is going to be there anyway<br> <emilio> q- was about to make a similar argument as noam<br> <bramus> … can say the solution is a document VT<br> <emilio> q-<br> <astearns> ack emilio<br> <astearns> ack flackr<br> <Zakim> flackr, you wanted to JakeA, i think we should allow setting name to none, and still make group<br> <bramus> flackr: donts e eproblem with capturing things without a name<br> <bramus> q+<br> <bramus> … can give them a special name<br> <bramus> … dont feel so strongly that I want to oppose a resolution here<br> <bramus> … can have v-t-name: none and it would still create a group<br> <JakeA> +1<br> <astearns> ack bramus<br> <ydaniv> bramus: styling VT-name none and still have captured, and pseudo element created, is hard to explain to authors<br> <emilio> To be clear I don't feel too strongly about allowing none, but I do think the whole doc is a bit special<br> <vmpstr> +1 to emilio<br> <ydaniv> flackr: the pixels aren't captured, we just create something that captures the root's scope, not the image<br> <ydaniv> bramus: I think this is weird because everything has to be backed by somehting in the UA stylesheet<br> <JakeA> q+<br> <ydaniv> ... the thing being captured has a name, and that is what caused it<br> <ydaniv> vmpstr: would be backed by having group contain<br> <noamr> ::view-tranisition-group(-ua-scope-root)<br> <vmpstr> q+<br> <ydaniv> bramus: also if you do VT group on bunch of elements then they suddnley also get captured even when they have no name<br> <ydaniv> ... hard to explain to ppl<br> <ydaniv> ... the properties and values do something that's confusing<br> <astearns> ack JakeA<br> <bramus> JakeA: common complaint from devs is that htye have a button taht triggers the VT and the button doenst move and when the press it the hove r style disappaears<br> <bramus> … with scoped we can hope it is outside of the scope<br> <bramus> … as olution wher ethe hover style contianues to do the right thing, sounds like a pretty good deal<br> <flackr> The vt spec says something about a root element, couldn't this use the same unnamed root? https://drafts.csswg.org/css-view-transitions-2/#pseudo-element-root<br> <bramus> … so if the scope is not particiapting by default and the button has no, then it seems like the right thing is ??? of that?<br> <astearns> ack vmpstr<br> <bramus> vmpstr: I think you want the scope to parcipate by default<br> <bramus> … base use case is change its bg color, and if it doesnt participat eby default then thats weird<br> <JakeA> q+<br> <bramus> … re emilio, I think doc is special because ???. for scoped you control how much is particpating, so yes we lose interactivity of those elements but its up to the author to structure that.<br> <bramus> … author has fine-grained control<br> <bramus> … losing itneractivity … would like to see how actually important that is<br> <bramus> … do want to go back to say that the scope has to participate, and work on pointer events indendpenttly<br> <bramus> … dont want to block progress on this issue therefore<br> <bramus> JakeA: OK with that<br> <astearns> ack JakeA<br> <bramus> … if we decide dnow that UA stylesheet has `v-t-n: root !important` on it, what are the chances of us changing that in the fture?<br> <bramus> vmpstr: can measure that and the risk wont be too severe<br> <bramus> … can cautiously take it<br> <bramus> JakeA: ok with the resolution then<br> <bramus> astearns: how about skobes?<br> <bramus> skobes: what is the protocol here? need to be unanimous?<br> <bramus> astearns: if you think we are taking the wrong route you should say so<br> <bramus> skobes: tricky, had hoped for a resolution today but concerns about forcing self-participation<br> <bramus> astearns: need to take it back to the issue then … vmpstr, will you write up things and skobes reply then?<br> <bramus> … then hopefully a much shorter discussion in the future<br> <bramus> … and now on to the regular meeting<br> <noamr> present-<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12324#issuecomment-3638074185 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 December 2025 17:00:51 UTC