Re: [csswg-drafts] [css-view-transitions-2] How are auto-generated `view-transition-name`s exposed in JS APIs (#10978)

The CSS Working Group just discussed ``[css-view-transitions-2] How are auto-generated `view-transition-name`s exposed in JS APIs``, and agreed to the following:

* ``ACTION: Open new issue about whether `auto` exposes the ID from the ID attribute as a view-transition-name for pseudo-element matching``
* ``RESOLVED: [Pending async confirmation] we will use `match-element` in the Animations API when element identity is used``

<details><summary>The full IRC log of that discussion</summary>
&lt;bramus> noamr: how do autogenerated appear in things like getAnimations?<br>
&lt;khush> q+<br>
&lt;bramus> … what would these auto-generated ones look like? Aavailble as strings? Or give them a name of `match-element` or `*` or not show them at all?<br>
&lt;fantasai> ACTION: Open new issue about whether `auto` exposes the ID from the ID attribute as a view-transition-name for pseudo-element matching<br>
&lt;bramus> bramus: and devtools?<br>
&lt;astearns> ack khush<br>
&lt;bramus> noamr: no, not included<br>
&lt;bramus> khush: two options<br>
&lt;bramus> … if we decied that id based names ar ehidden from css then it makes sense to hide everything from auto<br>
&lt;bramus> … or if name came from id attribute then do expose it but dont expose the identity ones (and expose those as `match-element`)<br>
&lt;bramus> q+<br>
&lt;bramus> astearns: the ids that auto uses could be made opaque but if the author uses the attr() fn then they would be exposed?<br>
&lt;bramus> khush: thats the complication with hiding ids<br>
&lt;bramus> … if you use attr() then you have all those complications of where you get the strings from<br>
&lt;astearns> ack bramus<br>
&lt;bramus> … can punt on this until we decide how to namespace ids<br>
&lt;noamr> q+<br>
&lt;fantasai> bramus: if value derived from ID attribute and expose it, if you have an element with an ID on one page and a different one on a different page with a view-transition-name of hero, then one transitions to the other<br>
&lt;fantasai> bramus: would be useful to expose that name<br>
&lt;fantasai> bramus: if we fall back to match-element strategy, then show that as match-element<br>
&lt;fantasai> bramus: because authors can't target those elements directly<br>
&lt;fantasai> bramus: by having match-element there, clearly can't target<br>
&lt;bramus> fantasai: q about whether id on one page would match a v-t-n on other is part of the namespacing discussion<br>
&lt;bramus> … dont have an opionion on direction<br>
&lt;bramus> … if that worked, then we should make pseudos match that<br>
&lt;bramus> … but q is then should that work in the first place?<br>
&lt;bramus> … do we want to expose the name derived from an id in the first place? no opinion right now.<br>
&lt;bramus> … obviously should not expose autogenerated names<br>
&lt;astearns> ack noamr<br>
&lt;bramus> noamr: strong opinion about keeping things simple… if generated by id its just that name<br>
&lt;bramus> … already doing complicated things that look different<br>
&lt;bramus> … if the v-t-name comes from an id, then that should be the v-t-n<br>
&lt;bramus> … if author dont want that, they should do other things<br>
&lt;bramus> … lets keep things flat<br>
&lt;khush> q+<br>
&lt;bramus> … regardless we can resolve to use the name `match-element` in `getAnimations`<br>
&lt;astearns> ack khush<br>
&lt;bramus> khush: since we are going here … my alignment is wit noam on this. keep it simpel and treat them as names<br>
&lt;bramus> … dont have author feedback on this though<br>
&lt;bramus> … not a super strong opinion<br>
&lt;bramus> … if this pattern is adopted like anchor-name and there is no matching concept, do we want to have this namespacing concept across css props then?<br>
&lt;bramus> … then VT wont have this own special thing<br>
&lt;bramus> q+<br>
&lt;bramus> … concept would make sense across CSS<br>
&lt;bramus> fantasai: none of the others have a way of pulling element id<br>
&lt;bramus> khush: but can imagine anchor-pos doing the same over time<br>
&lt;astearns> ack bramus<br>
&lt;noamr> I like that auto === id ? attr(id) : match-element<br>
&lt;bramus> bramus: missed<br>
&lt;bramus> astearns: but flatness isnt part of the issue<br>
&lt;bramus> khush: lets thing about that a bit more<br>
&lt;bramus> s/khush/noamr<br>
&lt;bramus> noamr: lets resolve on exposing them as `match-element`<br>
&lt;bramus> astearns: is ther ea conclict there?<br>
&lt;bramus> noamr: its just in getAnimations<br>
&lt;bramus> astearns: which is wrapped in a pseudo<br>
&lt;bramus> khush: compat risk for users that have used `match-element`<br>
&lt;bramus> bramus: dont think anyone has used that yet<br>
&lt;bramus> khush: so if you use auto and we use the id attr then we expose the id attr as string, and if we use identity then we expose match-element<br>
&lt;bramus> noamr: and tbd if these id-based names are namespaced or not<br>
&lt;bramus> astearns: should open an issue that<br>
&lt;bramus> khush: can do that<br>
&lt;bramus> PROPOSED RESOLUTION: we will use `match-element` in the Animations API when element identity is used<br>
&lt;bramus> astearns: objections?<br>
&lt;bramus> (silence)<br>
&lt;bramus> RESOLVED: [Pending async confirmation] we will use `match-element` in the Animations API when element identity is used<br>
</details>


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


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

Received on Wednesday, 30 October 2024 15:49:24 UTC