[css-animations-2] List of pseudo-elements in composite order is non-exhaustive

[george-steel]

In the definition of Animation composite order, the list of pseudo-elements only includes ::marker, ::before, and ::after. Since many other pseudo-elements exist, and there is no section of the spec restricting animations to these particular pseudo-elements, How should we resolve this? I can think of a few possibilities.

1. Replace the specific list with "pseudo-elements in alphabetical order by selector", as is done to order transitions by property.
2. Add an entry for "other pseudo-elements in alphabetical order by selector".
3. Add a canonical ordering to the pseudo-element spec and reference it. This would have to keep up with changes.
4. Add a restriction on which pseudo-elements may be animated to css-animations-1 and web-animations

[george-steel]

@birtles @stephenmcgruer

[birtles]

At this point I tend to lean towards (4) (and work out the ordering for other pseudos once UAs actually need to animate them).

I don't particularly like (1) since I believe the ::marker, ::before, ::after ordering makes most sense when authoring.

[george-steel]

My personal leaning is towards 2.

In the current spec, all pseudo-elements should be able to be targeted for animations (since we removed the requirement for EventTarget to make sense for the pseudo-element) and only animating before, after, and marker is a partial implementation. Restricting which pseudo-elements may be animated seems rather arbitrary.

[birtles]

I guess the question is, is Blink looking to implement animation for other pseudos in the near future? If not, I don't think we should spec it yet.

[george-steel]

I'm hoping to do so as long as the code doesn't fight back too much. Our current implementation of hanging Animations off of blink::PseudoElement objects (likely the source of the restriction) has lifecycle issues and needs refactoring anyways, fixing it might make all pseudo-elements animatable. I don't think we should de-spec it just now.