Re: [csswg-drafts] [css-view-transitions-1] Should view transition names be tree scoped? (#10145)

The CSS Working Group just discussed `[css-view-transitions-1] Should view transition names be tree scoped?`, and agreed to the following:

* `RESOLVED: view-transition-name lookup is tree-scoped`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> khush: Spec currently traverses all DOM elements, including those in shadow DOM<br>
&lt;fantasai> khush: Suggestion is to limit to tree-scoped<br>
&lt;TabAtkins> +1 to this<br>
&lt;fantasai> khush: so this would exclude things in shadow DOM<br>
&lt;fantasai> astearns: I've written some tests for tree-scoping, btw, and interop is terrible<br>
&lt;fantasai> khush: Are you talking about other features that are similar?<br>
&lt;fantasai> astearns: Yeah, I did @property rules and @xxx rules, which are supposed to be tree-scoped, and they're not handled correctly<br>
&lt;astearns> zakim, open queue<br>
&lt;Zakim> ok, astearns, the speaker queue is open<br>
&lt;fantasai> astearns: so probably some other things are also broken<br>
&lt;emilio> fantasai: two things, khush does this mean that for v-t that you'll never be doing transitions on anything in the shadow dom?<br>
&lt;emilio> khush: yeah this means that you couldn't use something inside the shadow dom as an independent thing<br>
&lt;kizu> q+<br>
&lt;emilio> ... scoped transitions would allow you to do that<br>
&lt;emilio> ... but only as a unit inside the DOM<br>
&lt;emilio> fantasai: to alan, there's two different kinds of scoping, at-rules and name defining<br>
&lt;emilio> ... those are quite different mechanism<br>
&lt;astearns> ack kizu<br>
&lt;fantasai> s/defining/defining on elements/<br>
&lt;emilio> ... I'd expect less issues with things like timeline scopes and so on<br>
&lt;fantasai> kizu: Wrt other scoping things, we also have timeline-scope and anchor-name<br>
&lt;fantasai> kizu: Might want to have a way to expose these names, since might have cases where you want to expose<br>
&lt;khush> q+<br>
&lt;fantasai> kizu: maybe this is a more general issue that we need to handle in CSS, and have it work consistently<br>
&lt;astearns> ack khush<br>
&lt;TabAtkins> +1, we need a general mechanic for weakening shadow encapsulation<br>
&lt;TabAtkins> But we should be consistent for now<br>
&lt;fantasai> khush: kizu's point reminds me of ::part(), could use CSS to expose names from within shadow DOM outside it<br>
&lt;fantasai> khush: maybe if you expose the element could allow it to match<br>
&lt;fantasai> khush: could make it more complicated to implement<br>
&lt;fantasai> khush: we already have things in the platform that allow such information, in those cases do you want naming in CSS to also be exposed?<br>
&lt;fantasai> astearns: That would be a separate feature, though. This is for default behavior for view transitions<br>
&lt;fantasai> khush: Does it make sense to make this resolution cover other cases also? Have a general principle<br>
&lt;fantasai> astearns: I think a separate issue on general mechanism, because we do want to consider them all<br>
&lt;fantasai> astearns: don't want to have a specific escape route just for VT<br>
&lt;TabAtkins> Agree, separate issues<br>
&lt;fantasai> RESOLVED: view-transition-name lookup is tree-scoped<br>
</details>


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


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

Received on Wednesday, 8 May 2024 16:13:44 UTC