- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jun 2024 13:08:05 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[view-transitions-2] Add method to get all animations of a ViewTransition object`, and agreed to the following:
* `RESOLVED: Add a pseudoElement option to the element.getAnimations() dict arg. subtree:true/false acts on that pseudo as the root`
* `RESOLVED: Add .transitionRoot readonly property to VT object, reflectring the element hosting the VT.`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> vmpstr: there's some desire to get all the VT animations (the animations associated with the VT pseudos)<br>
<TabAtkins> vmpstr: The proposal started with like adding .getAnimations() to the VT object<br>
<TabAtkins> vmpstr: but the current proposal is to add a pseudo parameter to element.getAnimations()<br>
<vmpstr> document.documentElement.getAnimations({ subtree: true, pseudoElement: "::view-transition" })<br>
<TabAtkins> vmpstr: so that would mean get all the animations in the subtree, that are on the ::view-transition pseudo-element<br>
<TabAtkins> vmpstr: yehonatan also had an idea for a selector filter for these<br>
<TabAtkins> vmpstr: havne't thought thru that yet, but just adding the pseudo property as a first step makes sense<br>
<TabAtkins> vmpstr: we'd also like to add a v-t-root property<br>
<ydaniv> q+<br>
<emilio> q+<br>
<flackr> q+<br>
<khush> q+<br>
<TabAtkins> vmpstr: For now this is always the documentElement, but for scoped transitions it woudl be valuable. Lower priority for now.<br>
<TabAtkins> vmpstr: So with this, you could get the transitioning root for a VT, then ask for all the animations from that element<br>
<astearns> ack ydaniv<br>
<TabAtkins> ydaniv: If we're adding a pseudo argument, i think the interaction with subtree is a bit funky<br>
<TabAtkins> ydaniv: if it's just to get the animations of *that* pseudo-element, that makes sense on its own<br>
<TabAtkins> ydaniv: but in this case you have an entire subtree under the pseudo, that's why you need subtree?<br>
<TabAtkins> flackr: the pseudo is establishing the root node you're interacting with<br>
<TabAtkins> flackr: so you could use it with subtree:false as well to get just from that pseudo<br>
<TabAtkins> flackr: but with subtree:true it includes the subtree of that pseudo<br>
<TabAtkins> ydaniv: It just seems weird to have somethign special just for a pseudo-element, which takes sort of a selector, and not have a more general api for a selector filter<br>
<TabAtkins> flackr: all fo this is based on pseudo-elements not being properly implemented. element.animate() takes a pseudo, etc. We just don't have an APi to interact with pseudos right now.<br>
<TabAtkins> ydaniv: okay, then no objection.<br>
<flackr> q-<br>
<TabAtkins> bramus: the gist is you're changing the root, not filtering<br>
<astearns> ack emilio<br>
<bramus> TabAtkins: (backs that up in more words)<br>
<TabAtkins> TabAtkins: Right, you just *don't get the animations* on the pseudoes right now<br>
<khush> q-<br>
<TabAtkins> emilio: I think my objection was addressed by rob, wondered if it needed to work with subtree:false. but that makes sense now.<br>
<TabAtkins> emilio: does anyone know offhand what getAnimations() does for ::before/after/etc with subtree:true?<br>
<TabAtkins> flackr: they're included<br>
<TabAtkins> vmpstr: Yeah, they'r eincluded, but since they're on the documentelement you end up getting *all* the animations on the whole page<br>
<khush> q+<br>
<TabAtkins> emilio: okay, that contradicted what Tab said at first<br>
<TabAtkins> TabAtkins: yeah i was just wrong<br>
<TabAtkins> khush: if you use a pseudo with element.animate(), and that could match multiple pseudos, what do we do with that?<br>
<TabAtkins> khush: should we do the same behavior here?<br>
<TabAtkins> flackr: I think you want it to mean all the ones that match<br>
<bramus> TabAtkins: I dont remember what we did for element.animate but since we are querying here but not taking action it seems fine<br>
<vmpstr> +1<br>
<TabAtkins> seems fine to just return all of them when multiple pseudos match, that is<br>
<TabAtkins> astearns: so summary?<br>
<TabAtkins> vmpstr: Add a pseudoElement option to the element.getAnimations() dict arg<br>
<TabAtkins> vmpstr: And subtree:true/false acts on that pseudo as the root<br>
<TabAtkins> astearns: objections?<br>
<TabAtkins> RESOLVED: Add a pseudoElement option to the element.getAnimations() dict arg. subtree:true/false acts on that pseudo as the root<br>
<TabAtkins> astearns: should we resolve on the how to get the element from the transition object?<br>
<TabAtkins> vmpstr: I don't think it's controversial, so if we could resolve that's great<br>
<ydaniv> read-only property<br>
<TabAtkins> vmpstr: new property on the VT object that's like .transitionRoot<br>
<flackr> q+<br>
<khush> +1 to read-only<br>
<TabAtkins> vmpstr: read-only, returns the element that's hosting the VT<br>
<astearns> ack khush<br>
<astearns> ack flackr<br>
<TabAtkins> flackr: might suggest .target, that's what animations use to say what they're animating<br>
<TabAtkins> vmpstr: sounds fine to me<br>
<TabAtkins> bramus: I'm a bit more of a fan of transition root, but we can talk about it later. I use the term "transition root" when speaking about it, "target" is a little more ambiguous of a term.<br>
<TabAtkins> flackr: we can bikeshed the name. I'm good witha dding the accessor, dont' want to delay.<br>
<bramus> s/but we can talk about it later. I /because when talking about I<br>
<TabAtkins> astearns: so proposed resolution is to add a readonly .transitionRoot to the VT object<br>
<TabAtkins> emilio: what type does it return?<br>
<TabAtkins> vmpstr: an Element<br>
<TabAtkins> TabAtkins: can you VT on a pseudo-element?<br>
<TabAtkins> vmpstr: No, you ahve to invoke a JS method<br>
<TabAtkins> emilio: sounds good<br>
<TabAtkins> RESOLVED: Add .transitionRoot readonly property to VT object, reflectring the element hosting the VT.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9908#issuecomment-2165621635 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 June 2024 13:08:06 UTC