[web-animations-1] What if the effect target is a nested pseudo-element?

[Loirooriol]

From https://drafts.csswg.org/web-animations-1/#keyframe-effects,

In order for the effect target to have a well-defined lifecycle, it is represented as an Element known as the target element and a pseudo-element selector knows as the target pseudo-selector. If the effect target is an Element, the target element is that element and the target pseudo-selector is null. If the effect target is a pseudo-element, the target element is its originating element and the target pseudo-selector is as required to specify that particular pseudo-element.

This seems to assume that pseudo-elements are always originated by an element. But nested pseudo-elements are originated by another pseudo-element.

So what happens if the effect target is a nested pseudo-element like ::before::marker?

I see 3 reasonable possibilities:

• The target element is the originating element of the ::before, and the target pseudo-selector is ::before::marker.
  That is, enforce the target element to be an Element, never a CSSPseudoElement, and let the target pseudo-selector be multiple pseudo-element selectors.
• The target element is the CSSPseudoElement represeinting the ::before, and the target pseudo-selector is ::marker
  That is, enforce the target pseudo-selector to be at most a single pseudo-element selector, and let the target element be either an Element or a CSSPseudoElement. Just forbid the case of the target element being a CSSPseudoElementand the target pseudo-selector being null.
• Get rid of the target pseudo-selector, let the target element equal the effect target, either an Element or a CSSPseudoElement.

[birtles]

I believe the reasoning behind that edit was to get away from having a dependency on CSSPseudoElement so I suspect we'll want to go with the first of the three possibilities (i.e. ::before::marker) here.

@george-steel Are you able to make that edit?

[Loirooriol]

It would be good if the solutions here and in #4456 were consistent.

[george-steel]

I would say this resolving this is blocked on #4456 at the moment. We should see what getComputedStyle does and match that behavior. One question I have is are there currently any pseudo-element selectors that do not commute (i.e. they car valid with different meanings in either order). My current mental model if PseudoElement semantics is that they control alternate style slots and any given piece of styled content is controlled by a set of them.

[george-steel]

Also isn't the originating element of a pseudo-element always an Element, even using a double-selector. something like ::before::marker would be the pseudo-selector. We already have this with ::before::first-line and all its weird inheritance rules.

[Loirooriol]

@george-steel According to https://drafts.csswg.org/selectors-4/#typedef-pseudo-element-selector, ::before::marker are 2 pseudo-element selectors, not just one.

And https://drafts.csswg.org/css-pseudo-4/#marker-pseudo says

an originating element that is a pseudo-element needs to be explicitly specified in the selector, e.g. ::before::marker.

so no, the originating element can be a pseudo-element.

AFAIK ::before::first-line is an invalid combination. But ::first-line is not tree-abiding, so #foo::first-line can have fragments inside #foo::before.

[george-steel]

That is definitely a footgun with the definition of originating element. The intention of the spec change was that the target element is always an Element.

[Loirooriol]

We may need two separate concepts (as proposed in #3836 (comment)). But an originating element that can be a pseudo-element is useful. For example, some behavior of a marker is controlled by the list-style properties on the originating element. So list-style on #target affects #target::marker, and list-style on #target::before affects #target::before::marker. We don't want the list-style on #target to affect both #target::marker and #target::before::marker

[george-steel]

I think you're right, that parents (::first line in a child has both the child and the parent's ::first-line as parents) and originating element are different logical concepts. Any idea on how do disambiguate that?