You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-pseudo-4] should CSSPseudoElement have a pseudo() method? #3836
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?
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.
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.
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.)
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?
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
@frivoal@lpd-au@heycam Let me know if anything seems off, or if the edits seem to correctly reflect what we agreed here. (CSSOM stuff is not my forte, exactly.)
As a nitpick, I believe it would be helpful to readers for the definition of parent to say "originating element or originating pseudo-element" for the spec reference, but maybe that's redundant and unnecessary since the rest of the definition already points to sub-pseudo-elements... (I'm no expert either!)
@lpd-au I think that would downplay the idea that an “originating element” can be either an element or a pseudo-element, i.e. that “originating pseudo-element” is defined as a sub-class of “originating element”. Since the next sentence explicitly mentions the case of having an originating pseudo-element, the intent should be clear from the spec already, so I think we don't particularly need to call it out. At least, that's my thinking. Lmk if that makes sense. :)
Activity
emilio commentedon Apr 17, 2019
I'd much rather not make
Element.pseudo()return pseudo-elements which are really other elements like::slottedor::part. They can match multiple elements at once I don't know what a sane return value for that would be.heycam commentedon Apr 18, 2019
That's a great reason for not doing it for those pseudos. :-) Are there other pseudos where it still might make sense?
emilio commentedon Apr 18, 2019
You could addres the
::markerthat::beforeand::aftercreate themselves... But it'd be weird to be able to target them via this API but not via CSS Selectors.tabatkins commentedon Apr 25, 2019
I've opened #3876 to discuss that, it is indeed weird.
birtles commentedon Apr 25, 2019
Even if we don't have
pseudo()onCSSPseudoElementitself, provided you can start a CSS animation/transition on the::markerfor a::before(which I assume will be the case once #3876 is resolved), what should we return as the animation target in that case?CSSPseudoElementwithtype'::before::marker' andelementas per an un-stacked pseudo (i.e. the actual originating DOMElement)?type'::marker' andelementthe parentCSSPseudoElement?type'::marker' and the originating DOMElement? (Making it indistinguishable from the::markerpseudo on theElement.)tabatkins commentedon Apr 25, 2019
Should be the second; it's a ::marker whose originating element is the ::before.
birtles commentedon Apr 25, 2019
Ok, I guess we need to change the type of
CSSPseudoElement.elementfromElementto(Element or CSSPseudoElement).tabatkins commentedon Apr 26, 2019
Yeah. And add
.pseudo()toCSSPseudoElement. ^_^heycam commentedon Apr 30, 2019
Maybe rename
CSSPseudoElement.elementto something likeparent?heycam commentedon Apr 30, 2019
Also, what's the story for getting computed style of these "stacked" pseudo-elements?
birtles commentedon May 2, 2019
It used to be named that (or
parentElementactually), but in #2816 it was pointed out that that was wrong andoriginatingElementwas too long so it becameelement. In this world of stacked pseudos, maybeparentis actually now correct?css-meeting-bot commentedon May 8, 2019
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
8 remaining items
[css-pseudo-4] Define CSSPseudoElement.parent (vs CSSPseudoElement.el…
[css-pseudo-4] Define CSSPseudoElement.pseudo() #3836
fantasai commentedon Dec 31, 2021
Edits in. I had to add a new section to Selectors 4 also. See
https://drafts.csswg.org/selectors-4/#sub-pseudo-elements
and
https://drafts.csswg.org/css-pseudo-4/#cssom
once it all regenerates.
@frivoal @lpd-au @heycam Let me know if anything seems off, or if the edits seem to correctly reflect what we agreed here. (CSSOM stuff is not my forte, exactly.)
frivoal commentedon Dec 31, 2021
Not an OM expert either, but it looks good to me.
lpd-au commentedon Jan 9, 2022
This looks great to me, thanks for your work! :)
As a nitpick, I believe it would be helpful to readers for the definition of
parentto say "originating element or originating pseudo-element" for the spec reference, but maybe that's redundant and unnecessary since the rest of the definition already points to sub-pseudo-elements... (I'm no expert either!)fantasai commentedon Dec 29, 2022
@lpd-au I think that would downplay the idea that an “originating element” can be either an element or a pseudo-element, i.e. that “originating pseudo-element” is defined as a sub-class of “originating element”. Since the next sentence explicitly mentions the case of having an originating pseudo-element, the intent should be clear from the spec already, so I think we don't particularly need to call it out. At least, that's my thinking. Lmk if that makes sense. :)