- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 May 2025 16:18:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Element-scoped view transitions`, and agreed to the following: * `RESOLVED: Start specifying element-scoped view transitions in view transitions L2` <details><summary>The full IRC log of that discussion</summary> <emilio> noamr: view transitions are shipping in multiple browsers<br> <emilio> ... a big feature request has been having them element-scoped, so that they don't have to lock the whole document, and you can have multiple of them altogether<br> <emilio> ... started prototyping it, lots of open issues<br> <emilio> ... wanted to introduce the basics<br> <emilio> ... and see if we can resolve adding it as a draft with everything else as open issues<br> <emilio> ... what we want to add is not just the document can start a VT, but also on Element<br> <emilio> ... the pseudo-elements are attached to the element rather than document<br> <emilio> ... lots of open issues, need to figure out what to do if the element changes size, how the name resolution works, ...<br> <emilio> ... we feel confident enough that we can go forward and wanted to see if the WG is fine with adding a draft with the skeleton of this<br> <emilio> q+<br> <fantasai> scribe+<br> <fantasai> emilio: Is the main requested use case having multiple transitions at the same time, or keeping the document responsive etc.?<br> <fantasai> emilio: Having multiple of them doesn't seem untenable either<br> <fantasai> emilio: multiple document-level ones I mean<br> <fantasai> emilio: though it would require some coordination<br> <fantasai> emilio: but, wondered about extending the document one rather than adding nesting ones<br> <fantasai> emilio: can sidestep some of these issues<br> <fantasai> emilio: wanted to hear your thoughts ; not opposed to this<br> <emilio> noamr: those difficulties are the feature in a way<br> <emilio> ... we want to make this work in shadow dom and not worry about document-level things interacting<br> <fantasai> emilio: wondering, if you want to do some sort of independent transition, don't want to coordinate with everything that might start a transition<br> <fantasai> .... but that seems solveable in a way, with the current setup<br> <fantasai> emilio: you add a scope parameter to the document.startViewTransition<br> <fantasai> emilio: for that transition, you only scan for transitions in that subtree<br> <fantasai> ... only snapshot in that subtree<br> <fantasai> emilio: very similar to element.startVT but uses document infrastructure<br> <fantasai> emilio: thing you don't want is to depend on things changing around<br> <fantasai> emilio: I'm assuming the eventual setup will be similar<br> <fantasai> emilio: so maybe it's fine ...<br> <fantasai> emilio: but wondering how much you had considered that<br> <fantasai> noamr: We had, but let's add to open issues<br> <fantasai> ... easier to discuss individually<br> <fantasai> emilio: sure<br> <fantasai> noamr: Once we have a draft we can address things more piecemeal<br> <fantasai> astearns: How are these element-scoped transitions going to interact with document-level, does one win over the other?<br> <emilio> astearns: how does element and doc-level transitions interact?<br> <emilio> noamr: open issue, but names can't conflict at least, and there'd be some sort of contained view transition name to separate internal names<br> <emilio> ... in general you should be able to run both as long as names are not conflicting, external one would use the output of the scoped one<br> <emilio> ... think about a `<video>` or another replaced element<br> <emilio> astearns: vague concern about having a subset of the pages being transitioned having rendering and hit-testing suppressed<br> <emilio> ... something about spoofing clicks and what not<br> <emilio> ... but I don't have a specific attack in mind<br> <emilio> noamr: separate open issue about hit test suppression<br> <emilio> ... the scoped element itself would receive hit testing, just the internal elements wouldn't<br> <emilio> astearns: view-transitions L3?<br> <emilio> noamr: really rather not add another one<br> <emilio> ... I'd suggest keeping at L2 and if other impl requests it we can reduce its scope<br> <emilio> ack emilio<br> <emilio> ack fantasai<br> <astearns> ack fantasai<br> <emilio> fantasai: wrt levels seems one of the interesting things is working out how these things correspond to each other<br> <fantasai> https://drafts.csswg.org/css-view-transitions-2/#changes<br> <emilio> ... would be helpful to list additions from L1 to L2<br> <emilio> ... other than v-t-class is there anything not related to nesting/scoping?<br> <emilio> noamr: all the cross-doc stuff<br> <emilio> ... actually a lot of kitchen-sink things<br> <emilio> fantasai: gotcha<br> <emilio> ... if we end up splitting L2 might make sense to keep kitchen-sink in L2 and move stuff with L3<br> <emilio> q+<br> <emilio> noamr: wanted to merge L1 and L2<br> <astearns> ack emilio<br> <fantasai> s/stuff with/nesting and scoping stuff with L3/<br> <emilio> emilio: +1 to splitting L1 and L2<br> <emilio> astearns: other concerns?<br> <emilio> RESOLVED: Start specifying element-scoped view transitions in view transitions L2<br> <emilio> s/splitting/merging<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9890#issuecomment-2916914625 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 May 2025 16:18:45 UTC