Skip to content

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

Closed

Description

@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?

Activity

  1. emilio commented on Apr 17, 2019

    @emilio
    Collaborator

    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.

  2. heycam commented on Apr 18, 2019

    @heycam
    ContributorAuthor

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

  3. emilio commented on Apr 18, 2019

    @emilio
    Collaborator

    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.

  4. tabatkins commented on Apr 25, 2019

    @tabatkins
    Member

    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.

  5. birtles commented on Apr 25, 2019

    @birtles
    Contributor

    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.)
  6. tabatkins commented on Apr 25, 2019

    @tabatkins
    Member

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

  7. birtles commented on Apr 25, 2019

    @birtles
    Contributor

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

  8. tabatkins commented on Apr 26, 2019

    @tabatkins
    Member

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

  9. heycam commented on Apr 30, 2019

    @heycam
    ContributorAuthor

    Maybe rename CSSPseudoElement.element to something like parent?

  10. heycam commented on Apr 30, 2019

    @heycam
    ContributorAuthor

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

  11. birtles commented on May 2, 2019

    @birtles
    Contributor

    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?

  12. css-meeting-bot commented on May 8, 2019

    @css-meeting-bot
    Member

    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
  13. 8 remaining items

  14. fantasai commented on Dec 31, 2021

    @fantasai
    Collaborator

    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.)

  15. frivoal commented on Dec 31, 2021

    @frivoal
    Collaborator

    Not an OM expert either, but it looks good to me.

  16. lpd-au commented on Jan 9, 2022

    @lpd-au

    This looks great to me, thanks for your work! :)

    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!)

  17. fantasai commented on Dec 29, 2022

    @fantasai
    Collaborator

    @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. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions