[csswg-drafts] [web-animations-1] Dependency on CSSPseudoElement (#4301)

stephenmcgruer has just created a new issue for https://github.com/w3c/csswg-drafts:

== [web-animations-1] Dependency on CSSPseudoElement ==
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](https://www.w3.org/TR/css-pseudo-4/#CSSPseudoElement-interface) 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](https://www.w3.org/TR/css-pseudo-4/#highlight-pseudos) 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](https://www.w3.org/TR/css-pseudo-4/#first-line-pseudo) 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.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4301 using your GitHub account

Received on Thursday, 12 September 2019 17:28:32 UTC