[selectors] Child & descendant pseudo element combinators

[jakearchibald]

Right now, div::before::marker means: Select the ::marker pseudo elements, that are a child of a ::before pseudo element, that originate from a div.

There isn't a way to say: Select the ::marker pseudo elements, that originate somewhere within the pseudo element tree of a div.

It'd be great if we had a way to achieve this, such as:

• :> - select child pseudo elements. As in, div :> before :> marker would be equivalent to div::before::marker
• :>> - select descendant pseudo elements. As in, div :>> marker would enable the use-case above.

Future additions could include other combinators prefixed with :, such as :+, to target adjacent sibling pseudo elements.

---

This use-case came up in shared element transitions. Over there, we create pseudo-trees that are more complicated than (I think) we've seen in other features:

html
└─ ::page-transition(id)
   └─ ::image-wrapper
      ├─ ::outgoing-image
      └─ ::incoming-image

Our current model is to expose these through the following selectors:

• html::page-transition-container(id)
• html::page-transition-image-wrapper(id)
• html::page-transition-outgoing-image(id)
• html::page-transition-incoming-image(id)

However, these don't really communicate the structure, and won't play well with upcoming features like nesting, or :has.

We'd like to expose the pseudos as they're structured, so instead of:

::page-transition-outgoing-image(id) { /*…*/ }

It would be:

::page-transition(id) :>> outgoing-image { /*…*/ }

Which plays well with nesting:

::page-transition(id) {
  & :>> outgoing-image { /* … */ }
  & :>> incoming-image { /* … */ }
}

This would also allow for selectors like:

::page-transition(id):not(:has(:>> incoming-image)) :>> outgoing-image {
  /* … */
}

Note: According to #7463, the above won't be possible.

…which selects the outgoing-image pseudo element within a page-transition pseudo element, that doesn't also have an incoming-image. Although, for that particular case, I hope we can make something like this work:

::page-transition(id) :>> outgoing-image:only-child {
  /* … */
}

[Loirooriol]

Related: #4565

[jakearchibald]

Interesting! So with this proposal:

*, * :>> * { box-sizing: border-box }

…would apply border-box to everything.

[tabatkins]

I hashed this out with Jake last week, and like this proposal; it addresses several of the pain points I've run into with pseudo-element syntax over the years.

Small detail, probably obvious from the examples: when selecting into the "pseudo tree" of an element, the pseudo-elements are treated as having tagnames equal to their names, so you use type selectors to target them. div :> before hits a ::before pseudo, for example. This requires us to broaden the syntax of Selectors slightly to allow type selectors to also be functions, for things like div :> slotted(.foo), but that shouldn't be problematic.

Also, in chained pseudo-elements like ::before::marker, the ::marker is part of the *pseudo tree" of the before, so you do have to write * :> before :> marker; * :> before > marker won't work, as the before pseudo-element doesn't have a child element. The pseudo-descendant combinator :>> just descends down the pseudo-children links, so * |>> marker grabs all markers, even those of pseudo-elements.

Jake's listed motivations are all great, and why I'd like this. In particular, it would allow us to finally revise the data model of pseudo-elements to make some dang sense when combined with other features like relative selectors and nesting, which makes me very happy. The foo::bar syntax will finally no longer be considered a weird compound selector; it's just a legacy way to write the complex selector foo :> bar, with a proper combinator and everything.

[Loirooriol]

If :> is just a normal combinator, then this can address part of #2284 too:

something#very.long :> :is(before, after) /* something#very.long::before, something#very.long::after */

But this wouldn't work:

something#very.long:is(*, * :> after) /* something#very.long, something#very.long::after */

[tabatkins]

Right, it would do the first but not the second. The second is still changing the subject of the selector, which is something that a pseudo-class fundamentally cannot do. We don't allow .foo:is(*, * > *) (to select the foo element and its direct children) either.

[romainmenke]

just a note

:> seems to cause issues in tooling.
Quickly tested this in a sass and parcel-css playground and both just give up entirely.
PostCSS with popular plugins does a bit better and outputs something but also gives warnings. VSCode colors a lot in red but eventually recovers.

Making : the start of a combinator instead of a pseudo class or pseudo element will require a lot of work. It will take a while for the ecosystem to catch up to something like this :)

---

Update :

This would be a major improvement imo.

[jakearchibald]

:> seems to cause issues in tooling.

I don't think any new combinator will work out of the box.

[romainmenke]

I don't think any new combinator will work out of the box.

That I understand, but there is a subtle difference between a new combinator which isn't recognised as a combinator and something that causes tools to stop processing CSS.

This is all fixable, but it will take time and considerable effort.

---

I do think we need the :> operator or something very similar.

[jakearchibald]

Maybe we're saying the same thing, but every potential new combinator I try in https://parcel-css.vercel.app/ fails, except something like ::descendant(foo), and that kind of thing is prohibitively long.

Have you found something that could work better?

[romainmenke]

Have you found something that could work better?

No and I think :> is very expressive and the best choice for the feature.

I've also been looking at the other side in tools -> how many bugs there are because .foo::before is seen as a compound selector and this is quite extensive. 4 of those were created by me in PostCSS plugins (all which have been fixed).

So my initial opinion has changed from "this will be a lot of work" to "this will be a lot of work and a whole class of bugs might get fixed"

[Loirooriol]

Typically, if a complex selector matches an element, you can take just the last compound selector and it will still match.

So if div :> before matches a pseudo-element and :> is a normal combinator, does it mean that a before alone will start matching pseudo-elements? Or are pseudo-elements featureless and can only be matched if there is a ::, :>, :>>? Will before :> marker match a ::before::marker?

[tabatkins]

This cuts into the same issue as when we had the /deep/ combinator proposed for Shadow DOM. Short answer is no, the invariant tightens to being "last compound selector before a tree-hopping combinator", since the initial set of elements visible to selectors are only those in a given tree.

[fantasai]

Suggest using :: instead of :> and ::: instead of :>>.

[romainmenke]

Tab previously looked into :: : #2284 (comment)

[tabatkins]

Yeah, :: is entirely unusable for reasons we will never be able to get around. That well is poisoned, dug up, then exploded for good measure.

And without ::, ::: doesn't make a lot of sense.

[fantasai]

I'd like to bring up @bradkemper’s response to that old thread here:

I disagree. I don't find it "much more understandable." In fact, I think having "::foo" as one chunk of text (no spaces) makes it much more clear that "foo" is not looking a element in the markup, but is instead something special (an element created by the CSS and then selected).

It might be a little more clear if there is a space before the "::". But honestly, I didn't have any problem parsing "p::before:hover::marker" in my mind. Because I have learned what "::" means already, and learning it with no spaces wasn't hard.

[css-meeting-bot]

The CSS Working Group just discussed [selectors] Child & descendant pseudo element combinators, and agreed to the following:

• RESOLVED: Start selectors 5 with the experimental work from this issue

The full IRC log of that discussion

Topic: [selectors] Child & descendant pseudo element combinators
github: https://github.com//issues/7346
TabAtkins: We've had for a little while a minor problem where pseudo elements inside pseudo elements have been tricky to target
TabAtkins: Repeatedly written incorrect rules that do not correctly target. *::marker doesn't hit inside ::before
TabAtkins: This will get more problematic over time as we add things like shared element transitions with a family of nested pseudo elements. Targetting a grandchild of a transistion element you have the name the transition tag regardless of where because can't meaningfully use target
TabAtkins: You can't save effort with nesting either
q?
TabAtkins: Jake came up with the idea of having a combinator that can select into pseudo tree as a descdendant combinator. You say a name and you find it regardless of how nested it is
TabAtkins: Suggested syntax is :> for child pseudo combinator and :>> for the new descendant that goes asdeep as needed
'arrow' being '>', not '->'
TabAtkins: Specifics is when you use this combinator pseudo elements are elements with tag that is their element. :: is not part of the name
q+
TabAtkins: I think that's the specifics. Allows us to greatly simplify and write code targetting, for example, ::marker
TabAtkins: Thoughts?
heycam: Can you summerize why not possible to use regular child and descendants once past first ::? If we're considering things inside top level can we use regular tag name matching?
heycam++
TabAtkins: Issue with doing that, first is would not let you generically select into psuedo trees. That feels not great that you have to enter the pseudo tree with a specific name and then you can do arbitary.
ack heycam
TabAtkins: Slightly more important issue is it presupposes we don't event use child relationships in any other way which I'm not certain we want to guarantee. Some pseudo elements refer to real elements like ::slotted. Right now can't access further into tree but I don't know why we wouldn't do that in the future
See also https://www.w3.org/TR/2014/WD-css-scoping-1-20140403/#fragment-scoping
TabAtkins: instead idea here is there's a separate relationship and this combinator only goes across pseudo/child relationship
heycam: Makes sense
fantasai: one specific area we thought about this is ::page or ::colun type things and being able to pick elemental fragments in that fragmented region.
fantasai: We had thought about doing something where you can style black and white columns differently which needs you to enter the tree
Rossen_: fantasai I saw your last comment lifting BradK's old response. Is this something we want to repeat here?
fantasai: I think I was pulling up old comments. Haven't thought deeply to have a conclusion. Idea of going deeper into pseudo tree makes sense. I think bradk comment was we ID psuedo elements with a name that begins ::. The pseudo element is named :: which is how we know it's not real. This prop breaks that naming association
fantasai: I think it's a comment worth thinking about.
fantasai: Idea of using combinator syntax I can see benefits to it. I'm trying to think what's a way of keeping these considerations and bring together. Maybe instead of :> we do ::> so maybe still association with pseudo element so at least you've got two :s
TabAtkins: Using ::>?
fantasai: Yeah
TabAtkins: That would be fine. I suggested : to suggest pseudo, but more explict ::> is fine
q+
TabAtkins: Obvious solution is :: as combinator and for reasons I explored years ago that's unfortunately impossible due to selector syntax. But it would be fine with ::> and ::>>
ack vmpstr
vmpstr: I wanted to ask how would this interact with :has?
vmpstr: Presumably to know if there is a pseudo element you need up to date style and I don't think we do this now. And with :has you can make it display:none
TabAtkins: Good question. B/c pseudo elements always exist or conditionally exist I suggest answer is :has can't see pseudo elements when you select that deep. We can address it in the future if there's a need, but I would say we should make it invalid to use the combinator
fantasai: Should we also make pseudo elements invalid in has in general?
ч?
TabAtkins: I don't know
fantasai: Has the same problem
q?
TabAtkins: Not sure you can write selectors that are problematic. If you can we should
fantasai: I suggest we make both invalid for now
Rossen_: Additional feedback for TabAtkins or Jake?
fantasai: I'd like to have a few more people weigh in but this overall makes sense to do this
TabAtkins: I can start laying down details in spec and we can get eyes once there's text. As long as no obvious objection now I'm happy
Rossen_: Not hearing any such objection from dozen or so people on the call
Rossen_: Let's move forward with spec. Once you have that hopefully more people will provide feedback
fantasai: RElated question, do we want to take a cut of selectors 4 to CR and redraft selectors 5?
TabAtkins: Think so and happy to put this in selectors 5
fantasai: Okay. Let's do that and you and I can work on taking a cut of selectors 4
TabAtkins: sgtm
Rossen_: Let's resolve on starting selectors 5 with the experimental work from this issue
Rossen_: Obj?
RESOLVED: Start selectors 5 with the experimental work from this issue
Rossen_: For selectors 4, any resolution for that at this point?
fantasai: We were going to make it invalid to use a pseudo element inside :has
Rossen_: Is this part of the issue or part of moving selectors 4?
fantasai: Related to this issue b/c this issue brought what happens if you put pseudo element in :has
jensimmons: We should open a new issue for that and give it more time
jensimmons: I don't think we should do it ahead of time b/c we think this is going to go through. We should look at present state
+1 to a separate issue to discuss async and bring it back for a resolution
fantasai: Yes, looking at current and think it's a problem for the same reason as in context of this discussion. I think it's something we didn't consider. Allowing url:has(::marker) is confusion and shouldn't be possible
ol:has(li::marker) is confusing and shouldn't be possible
jensimmons: Cool. How about open an issue for next week's agenda
Rossen_: I don't mind that at all since the proposed resolution also didn't come through to me clearly from the previous converation
Rossen_: Do we want to fork that into a new issue and slot it for next week? It will fit nicely with some other items we're skipping this week
fantasai: Okay
Rossen_: Next week we can take all the resolutions to move selectors 4 forward
Rossen_: fantasai will you open?
fantasai: Sure
Rossen_: Anything else on this issue?
https://github.com//issues/7463

[Loirooriol]

Some pseudo elements refer to real elements like ::slotted. Right now can't access further into tree

Actually, the spec allows things like ::shadow > p, https://drafts.csswg.org/selectors-4/#pseudo-element-structure

[tabatkins]

Yeah, but we undefined ::shadow, so no currently-existing pseudo-element allows it, I think. ^_^

[ExE-Boss]

See also #5472