[web-animations-1] Dependency on CSSPseudoElement

[stephenmcgruer]

If we ship getAnimations, by default we will expose animations on pseudo-elements (accessible via either document.getAnimations(), or element.getAnimations({subtree:true})). These animations may have been created by either CSS Animations or CSS Transitions (not Web Animations at time of writing, as Element.pseudo() has not shipped). The web developer can then call animation.effect.target, and get a handle to… what? CSSPseudoElement has not shipped, so what do we return here?

This issue explores options for how to handle this, so we can actually ship getAnimations.

Option 1 - ship CSSPseudoElement

The simplest option - 'just' ship CSSPseudoElement. This would obviously solve the problem, but it's unclear if the browser vendors generally agree with shipping it. The exact nature of the interface might still need work (and the spec says that more methods are likely to be added to it). This is very easy to implement for node-like pseudo-elements but would be nontrivial (due to inheriting EventTarget) to implement for first-line and selection.

Option 2 - Separate interfaces for Node-like pseudo-elements, ::selection, and ::first-line

The term pseudo-element currently refers to a number of different behaviors. Many of them (before, after, backdrop, and arguably first-letter) behave like auto-generated elements and support full styling. As such, inheriting from EventTarget makes sense for them (along with some mutators like animation). The CSSPseudoElement interface makes sense here.

Selection operates on an overlay system. In the spec, the highlighted areas are painted as if ::selection (which is restricted to non-layout properties) applies as a pseudo-class. First-line is even more unusual as the pseudo-element's styling (and that of its surroundings) affect the extent of its contents, thus there is no static node structure. It does not make sense for these to have a CSSPseudoElement interface that implements EventTarget.

If we separated out psuedo-elements into different types in the IDL, we could ship CSSPseudoElement for the types that make sense, and disallow animations on those that don't.

Option 3 - add pseudoSelector property to AnimationEffect

This option sidesteps the problem, but at the cost of developer ergonomics. The idea would be that a pseudo-element animation would still have a target of the underlying Element, and then a pseudoSelector property that would return the appropriate selector.

This would not be backwards compatible - we could not later on change target to return a CSSPseudoElement without (likely) breaking people.

Note that this would require a small change to the getAnimations algorithm, as currently it is spec'd as: "the set of relevant Animation objects that contain at least one animation effect whose target element is this object". This would need to also take pseudoSelector into account.

Option 4 - don't return psedo-element animations in getAnimations

Final option; just skip pseudo-element animations when calling getAnimations. This seems like it would have pretty bad backwards-compatibility problems - developers would likely assume they only get Elements back from getAnimations. We would probably need to add an option like {includePseudos:true} later on which would be sorta meh.

[birtles]

I had always assumed we would go with option 1, but without shipping Element.pseudo(). As a result, one could only get CSSPseudoElement objects via getAnimations() and hence could only get pseudo elements that are animatable, i.e. only node-like pseudo elements, and only ::before, ::after, and ::marker.

[graouts]

We're still discussing this very issue internally, but my inkling is that we'd ship CSSPseudoElement.

[stephenmcgruer]

Option 1 + not ship Element.pseudo() sounds good to me. Will start putting together a Blink intent-to-ship (since we'll need it for web-animations-1) for our side.

Any updates from your side @graouts ?

[birtles]

Option 1 + not ship Element.pseudo() sounds good to me. Will start putting together a Blink intent-to-ship (since we'll need it for web-animations-1) for our side.

Just checking, was that an intent-to-implement?

I'd like to talk about the behavior of CSS animations/transitions before shipping getAnimations(). (Also, I'm curious about your experience with the replacing behavior.)

[stephenmcgruer]

Just checking, was that an intent-to-implement?

Intent-to-ship, but for the CSSPseudoElement interface, not for getAnimations() or any animations stuff. It's a bit annoying, but we have an internal technical reason that makes it tricky to implement the CSSPseudoElement IDL behind a flag. We could still do it, but if everyone is on board with (a) shipping CSSPseudoElement and (b) shipping Web Animations v1 at some point (soon? soon...!) it seems easier to just ship the CSSPseudoElement interface.

... actually, now that I write that it seems really weird to ship the CSSPseudoElement interface without shipping any way to get to it. So maybe I'll just try to work around the problem and send an intent-to-implement instead... TBD. :D

I'd like to talk about the behavior of CSS animations/transitions before shipping getAnimations().

Is there something particular you have in mind? @flackr looked at this recently-ish and at the time he felt the story there seemed ok I believe.

(Also, I'm curious about your experience with the replacing behavior.)

@kevers-google is working on this atm, I believe its going well but that's at a very high level and we can discuss more at the next telcon :)

[birtles]

I'd like to talk about the behavior of CSS animations/transitions before shipping getAnimations().

Is there something particular you have in mind? @flackr looked at this recently-ish and at the time he felt the story there seemed ok I believe.

Yeah, I just wanted to check about the override/readonly behavior. In particular, I'm keen on doing very simple overriding since it dramatically increases the utility of the API for little complexity. And in either case we need to consider if the behavior of play()/pause()/animation-play-state is what we really want.

(Also, I'm curious about your experience with the replacing behavior.)

@kevers-google is working on this atm, I believe its going well but that's at a very high level and we can discuss more at the next telcon :)

Yep, sorry, I missed the last two telcons because I lost access to my mozilla.com account where the meeting was set up. Do you mind inviting brian@birchill.co.jp to the next one?

[stephenmcgruer]

Yep, sorry, I missed the last two telcons because I lost access to my mozilla.com account where the meeting was set up. Do you mind inviting brian@birchill.co.jp to the next one?

Oh sorry! We had invited your personal email, but I guess that was the wrong one :(. Added the new one to the event. Looking forward to having you back :)

[birtles]

Oh sorry! We had invited your personal email, but I guess that was the wrong one :(. Added the new one to the event. Looking forward to having you back :)

(It's odd but the invitations don't seem to have arrived at my personal email somehow. In any case, though, I received it at the other address, so thank you!)

[george-steel]

Code review for our implementation just opened up another can of worms at #4398.

[stephenmcgruer]

We discussed this issue today at the cross-browser Animations sync. Motivated by #4398 , we agreed that for compatibility with what we expect events will evolve to for CSSPseudoElement, we are going to drop web-animations-1's dependency on CSSPseudoElement and instead modify KeyframeEffect to have both a target and a pseudoElement selector string. To animate a pseudo-element, the web author would do something like:

element.animate(keyframes, { duration: 1000, pseudoElement: '::before' });

This is a significant change, and does have an impact on both web developers mental model of animations as well as arguably the ergonomics of the API. For example a given animation would not necessarily target its animation.effect.target - one must consider the animation.effect.pseudoElement selector too. Note that it is not (afaik) currently possible in any browser to obtain a JS handle to an animation on a pseudo-element, so we shouldn't be regressing on anything there.

Given the significance of the chance, adding this to CSSWG agenda to make sure it is visible and that the justification based on expected EventTarget changes (see below) are reasonable.

Event Target Justification

There are (many) existing events today that can be aimed at pseudo elements; 'click' being an obvious case. It is our understanding that currently such events have a target of the parent Element, rather than the (non-existent) CSSPseudoElement object.

In a world where CSSPseudoElement ships, it seems too breaking to have events (e.g. click) that target pseudo elements now return the CSSPseudoElement object for their target. Instead, we assume that they would follow the same style as css-transitions-1 or css-animations-1 events and add a pseudoElement selector to the event IDL (or we could just continue to rely on lovely hacks such as these? :D).

[birtles]

Note that it is not (afaik) currently possible in any browser to obtain a JS handle to an animation on a pseudo-element, so we shouldn't be regressing on anything there.

Not any release version of a browser. Firefox implements it in Nightly but it's preffed off in release channels. (If you use getAnimations({ subtree: true }) you'll get animations targeting CSSPseudoElement objects.)

I think beyond the implications for event targets, having to resolve all the lifetime issues relating to CSSPseudoElement objects is another motivation for wanting to avoid this dependency.

[css-meeting-bot]

The CSS Working Group just discussed Dependency on CSSPseudoElement, and agreed to the following:

• RESOLVED: Pseudo elements are targeted via a parent plus a pseudo selector

The full IRC log of that discussion

<dael> Topic: Dependency on CSSPseudoElement
<dael> github: https://github.com//issues/4301
<rego> rego: present+
<dael> Steven: I'm hoping this is a rubber stamp. Hopefully everyone has read
<AmeliaBR> s/Steven/smcgruer /
<astearns> s/Steven/smcgruer/
<dael> Steven: We have a problem where CSSPSeudoElement has a lot of questions. For animations events and objects want to spec Pseudo element by target being parent element. Similar to animations nad transitions
<dael> smgruer: We expect this is how all will have to for for pseudo elements. No way to change events that happen today.
<dael> smcgruer: Want to make sure makes sense for group
<dael> florian: There was another conversation on speudo events for highlighting and discussed with editing TF. Opinion of the Editing TF is it was inadequat so let's be careful how we use/expose
<dael> florian: Not expert, but there was discussion on changing how looks/works
<dael> Rossen_: I think the discussion florian referring to for highlight API were close to what's being proposed. From last I heard they want to start taking more dependency on this prop model. Another was inking input want similar exposure for various types of actions and states. Want to be able to target similar eventing model
<dael> Rossen_: I have read the proposal, I don't think it's controversial. Want to hear from more people working in this space.
<dael> Rossen_: Not hearing any.
<dael> Rossen_: Are you looking for a resolution smcgruer? That accepts the proposal?
<dael> smcgruer: Yeah
<dael> fantasai: I wanted to ask if birtles has weighed in and what's his position
<dael> smcgruer: My understanding is he agrees. Her was part of the discussion. But I can't represent him directly
<dael> Rossen_: I don't believe he was opposed. We can re-open and continue if it's not complete. It doesn't come across that birtles is against in the thread.
<dael> Rossen_: I propose we resolve and if there's additional conversations we ca re-open
<dael> fantasai: Okay with that is assumption is correct
<dael> AmeliaBR: What's the exact proposal?
<fantasai> s/is/if/
<dael> smcgruer: Prop: Animations have a target element. We prop for animations targetting pseudo elements is the target is the parent and an additonal selector that lets you know which the new element it
<dael> Rossen_: Pseudo elements are targeted via a parent plus a pseudo selector
<dael> AmeliaBR: Has anyone thought about forward compat for a pseudo element dom object?
<dael> smcgruer: Not extensively. That's fair. Problem in general is event targeting in general will have to solve that
<dael> AmeliaBR: True. We have events where event target is the element.
<dael> Rossen_: Even if go down path of exposing pseudo element as objects need to have a way to target through selectors. That way will have to work here. Only change to model is how to get to event target.
<dael> Rossen_: If we expand the pseudo family we have to figure out how to select. Not unique to this proposal
<dael> Rossen_: Objections?
<dael> RESOLVED: Pseudo elements are targeted via a parent plus a pseudo selector