csswg-drafts
csswg-drafts copied to clipboard
w3c
[css-view-transitions-2] How are auto-generated `view-transition-name`s exposed in JS APIs
Requesting a clarification for this resolution.
Do we want ::view-transition-{group|old|new|image-pair}(auto) to match pseudo-elements generated from the auto keywords, or do people need to use only classes to style them?
/cc @nt1m @fantasai @khushalsagar @vmpstr
I'd be fine either way. Ideally authors would use the view transition class but I don't see the harm in allowing auto to match any pseudo with an auto generated name.
Relates question, what should be the name of the pseudo for Animation objects returned by getAnimations. Should it also be ::view-transition-group(auto)?
Also, how should auto pseudo-elements appear in getAnimations({subtree: true})[...].effect.pseudoElement ? Probably also as auto? Or as *?
Exposing these as auto seems fine. Authors shouldn’t try to read the generated name for later use. In that case they should give the element a proper view-transition-name.
The net result is that you can end up with multiple ::view-transition-group(auto) entries in the ::view-transition pseudo, which I believe is OK.
To clarify my previous comment: I'm fine with exposing as auto in case the name was generated. If the name was derived from an attribute, then that attribute value would show up.
@bramus I wonder if the name derived from an attribute should be in a different namespace, e.g. ::view-transition-group(#name).
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 matchingRESOLVED: [Pending async confirmation] we will use `match-element` in the Animations API when element identity is used
The full IRC log of that discussion
<bramus> noamr: how do autogenerated appear in things like getAnimations?<khush> q+
<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?
<fantasai> ACTION: Open new issue about whether `auto` exposes the ID from the ID attribute as a view-transition-name for pseudo-element matching
<bramus> bramus: and devtools?
<astearns> ack khush
<bramus> noamr: no, not included
<bramus> khush: two options
<bramus> … if we decied that id based names ar ehidden from css then it makes sense to hide everything from auto
<bramus> … or if name came from id attribute then do expose it but dont expose the identity ones (and expose those as `match-element`)
<bramus> q+
<bramus> astearns: the ids that auto uses could be made opaque but if the author uses the attr() fn then they would be exposed?
<bramus> khush: thats the complication with hiding ids
<bramus> … if you use attr() then you have all those complications of where you get the strings from
<astearns> ack bramus
<bramus> … can punt on this until we decide how to namespace ids
<noamr> q+
<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
<fantasai> bramus: would be useful to expose that name
<fantasai> bramus: if we fall back to match-element strategy, then show that as match-element
<fantasai> bramus: because authors can't target those elements directly
<fantasai> bramus: by having match-element there, clearly can't target
<bramus> fantasai: q about whether id on one page would match a v-t-n on other is part of the namespacing discussion
<bramus> … dont have an opionion on direction
<bramus> … if that worked, then we should make pseudos match that
<bramus> … but q is then should that work in the first place?
<bramus> … do we want to expose the name derived from an id in the first place? no opinion right now.
<bramus> … obviously should not expose autogenerated names
<astearns> ack noamr
<bramus> noamr: strong opinion about keeping things simple… if generated by id its just that name
<bramus> … already doing complicated things that look different
<bramus> … if the v-t-name comes from an id, then that should be the v-t-n
<bramus> … if author dont want that, they should do other things
<bramus> … lets keep things flat
<khush> q+
<bramus> … regardless we can resolve to use the name `match-element` in `getAnimations`
<astearns> ack khush
<bramus> khush: since we are going here … my alignment is wit noam on this. keep it simpel and treat them as names
<bramus> … dont have author feedback on this though
<bramus> … not a super strong opinion
<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?
<bramus> … then VT wont have this own special thing
<bramus> q+
<bramus> … concept would make sense across CSS
<bramus> fantasai: none of the others have a way of pulling element id
<bramus> khush: but can imagine anchor-pos doing the same over time
<astearns> ack bramus
<noamr> I like that auto === id ? attr(id) : match-element
<bramus> bramus: missed
<bramus> astearns: but flatness isnt part of the issue
<bramus> khush: lets thing about that a bit more
<bramus> s/khush/noamr
<bramus> noamr: lets resolve on exposing them as `match-element`
<bramus> astearns: is ther ea conclict there?
<bramus> noamr: its just in getAnimations
<bramus> astearns: which is wrapped in a pseudo
<bramus> khush: compat risk for users that have used `match-element`
<bramus> bramus: dont think anyone has used that yet
<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
<bramus> noamr: and tbd if these id-based names are namespaced or not
<bramus> astearns: should open an issue that
<bramus> khush: can do that
<bramus> PROPOSED RESOLUTION: we will use `match-element` in the Animations API when element identity is used
<bramus> astearns: objections?
<bramus> (silence)
<bramus> RESOLVED: [Pending async confirmation] we will use `match-element` in the Animations API when element identity is used
@bramus I wonder if the name derived from an attribute should be in a different namespace, e.g.
::view-transition-group(#name).
@khushalsagar filed #11112 for that :)
The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.
Proposed Resolution: we will use match-element in the Animations API when element identity is used
I think we should discuss in a call, it'll be a first to have an identifier potentially return animations for multiple pseudo-elements.
@nt1m before we bring this back to a call, could you go into more detail here about your concerns?
I think we should discuss in a call, it'll be a first to have an identifier potentially return animations for multiple pseudo-elements.
To be clear, this is about returning ::view-transition-group(match-element) when calling e.g. document.documentElement.getAnimations({subtree: true})[0].pseudoElement; You can't address multiple elements with getComputedStyle etc.
^ Same for any element.animate. Basically any API (script or CSS selectors) which targets a specific pseudo won't work for element identity based matching.
match-element or auto can tag multiple elements at once, which one do you return from the JS API?
^ nothing. It's the equivalent of calling the API with an invalid selector / view-transition-name.
Seems weird that it would work when one element is running, but not multiple.
It will never work if the element's name is internal because it was based on node identity. Only id based and explicitly named elements can be targeted directly in CSS or script. Node identity based names must use classes for targeting in CSS and won't have support for script based APIs.
This can be fixed going forward if we have CSSPseudoElement IDL. We could add a getPseudos(class) type of API to grab all pseudos which have a class. In case the author wants to do a web animation on all of them. The alternate would be to augment all the existing APIs like getComputedStyle or element.animate to target multiple pseudos given a selector using view transition classes. But I'm not a fan of that, feels like we're continuing to work around the lack of CSSPseudoElement.
I'd be in favor in resolving if it's just for how to serialize (e.g. output). But 👎 to using match-element as input.
I'd be in favor in resolving if it's just for how to serialize (e.g. output). But 👎 to using
match-elementas input.
We're on the same page, this is only for output.
Yea, sorry for the confusion. This is about what shows up when the UA returns a pseudo element name.
That said, I do want to make sure we're aligned on the behaviour about input. getComputedStyle(documentElement, "::view-transition-group(match-element)") won't work. So if someone writes script where they get all the animations and then use the pseudoElement from the Animation object in getComputedStyle, that won't work.
RESOLVED: We will use match-element in the Animations API when element identity is used