[css-pseudo-4] should CSSPseudoElement have a pseudo() method?

[heycam]

https://drafts.csswg.org/css-pseudo-4/#CSSPseudoElement-interface

You can get to the pseudo-element of an element with Element.pseudo(). But some pseudos are defined to have other pseudos hanging off them, like with ::part(label)::before. Does CSSPseudoElement need its own pseudo() method?

[emilio]

I'd much rather not make Element.pseudo() return pseudo-elements which are really other elements like ::slotted or ::part. They can match multiple elements at once I don't know what a sane return value for that would be.

[heycam]

That's a great reason for not doing it for those pseudos. :-) Are there other pseudos where it still might make sense?

[emilio]

You could addres the ::marker that ::before and ::after create themselves... But it'd be weird to be able to target them via this API but not via CSS Selectors.

[tabatkins]

But it'd be weird to be able to target them via this API but not via CSS Selectors.

I've opened #3876 to discuss that, it is indeed weird.

[birtles]

Even if we don't have pseudo() on CSSPseudoElement itself, provided you can start a CSS animation/transition on the ::marker for a ::before (which I assume will be the case once #3876 is resolved), what should we return as the animation target in that case?

• Would it be a CSSPseudoElement with type '::before::marker' and element as per an un-stacked pseudo (i.e. the actual originating DOM Element)?
• Or would it have type '::marker' and element the parent CSSPseudoElement?
• Or just type '::marker' and the originating DOM Element? (Making it indistinguishable from the ::marker pseudo on the Element.)

[tabatkins]

Should be the second; it's a ::marker whose originating element is the ::before.

[birtles]

Ok, I guess we need to change the type of CSSPseudoElement.element from Element to (Element or CSSPseudoElement).

[tabatkins]

Yeah. And add .pseudo() to CSSPseudoElement. ^_^

[heycam]

Maybe rename CSSPseudoElement.element to something like parent?

[heycam]

Also, what's the story for getting computed style of these "stacked" pseudo-elements?

[birtles]

Maybe rename CSSPseudoElement.element to something like parent?

It used to be named that (or parentElement actually), but in #2816 it was pointed out that that was wrong and originatingElement was too long so it became element. In this world of stacked pseudos, maybe parent is actually now correct?

[css-meeting-bot]

The CSS Working Group just discussed CSSPseudoElement having a pseudo() method, and agreed to the following:

• RESOLVED: add .pseudo() to CSSPseudoElement once some stacked pseudo combination becomes a valid selector. Adjust .element return type to match.

The full IRC log of that discussion

<fantasai> Topic: CSSPseudoElement having a pseudo() method
<fantasai> AmeliaBR: Seems to make sense to me, if a pseudo-element can have a pseudo-element, then having .pseudo() would make sense
<fantasai> emilio: Have we decided yet how to make those styleable
<fantasai> fantasai: will be stylable with selectors like ::before::marker
<fantasai> emilio: I would wait to add this method until that is allowed
<fantasai> fantasai: So proposal is to add .pseudo() to CSSPseudoElement once stacked pseudo becomes a valid selector
<fantasai> plinss: Side issue of whether to rename .element to .parent
<fantasai> fantasai: Not always a parent
<fantasai> TabAtkins: The full term is "originating element" but that was too long
<fantasai> TabAtkins: So shortened to .element
<fantasai> plinss: Need to reach pseudo-element between you and the element
<fantasai> TabAtkins: Yeah, that's what .element would do
<fantasai> plinss: OK
<fantasai> TabAtkins: When we adopt this, just the return type would be adapted
<fantasai> RESOLVED: add .pseudo() to CSSPseudoElement once some stacked pseudo combination becomes a valid selector. Adjust .element return type to match.
<emilio> github: https://github.com//issues/3836