[css-selectors] Proposal: `>>` combinator to ensure all elements between an ancestor and a descendant match a given selector

[benface]

I've needed something like this a few times, and I just thought of a way to express it.

Here's an example:

<div class="group">
  <div> <!-- any number of element layers here -->
    <div class="yellow-bg-on-nearest-group-hover">
      This element should have a yellow background when the root `.group` is hovered, because it's
      the nearest one to this element.
    </div>
  </div>
  <div class="group">
    <div> <!-- any number of element layers here -->
      <div class="yellow-bg-on-nearest-group-hover">
        This element should have a yellow background only when the nearest `.group` is hovered,
        but not when other elements in the root `.group` are.
      </div>
    </div>
  </div>
</div>

Here's how I'm picturing it:

.group:hover > .yellow-bg-on-nearest-group-hover,
.group:hover > :not(.group) >> .yellow-bg-on-nearest-group-hover {
  background-color: yellow;
}

It would be equivalent to the following, but with an infinite number of > :not(.group) >:

.group:hover > .yellow-bg-on-nearest-group-hover,
.group:hover > :not(.group) > .yellow-bg-on-nearest-group-hover, 
.group:hover > :not(.group) > :not(.group) > .yellow-bg-on-nearest-group-hover
.group:hover > :not(.group) > :not(.group) > :not(.group) > .yellow-bg-on-nearest-group-hover /* etc. */ {
  background-color: yellow;
}

It would basically repeat the selector that precedes >> an infinite number of times.

[benface]

I just realized that a similar "continuous" combinator but for sibling elements (++), rather than ancestor/descendant, could make sense too, though I don't have a strong use case for it.

[ByteEater-pl]

You may consider:

@scope (.group:hover) to (.group:not(:hover)) {
	 .yellow-bg-on-nearest-group-hover {
		background-color: yellow;
	}
}

[benface]

Yes, thank you @ByteEater-pl! I realized the same thing (should actually be @scope (.group:hover) to (.group), but same idea). So maybe there's not as much value in my >> proposal as I thought; I would have to think about it more to know if there are problems that it solves that @scope doesn't solve, either at all or as nicely.

[ByteEater-pl]

I think @scope (.group:hover) to (.group) is equivalent to mine, but indeed simpler.

Although there are no use cases given here, the case of siblings (or, more generally, a range between two nodes in the styled document selectable in CSS) remains and looks interesting. Some shenanigans with & (nesting selector) and some of :not(), :nth-child(), :nth-last-child(), the latter two with of and a selector (or a list thereof) afterwards, might work, if only & (and maybe :has()) were allowed there. But it isn't so – all these locations require a <complex-real-selector-list>, which is very limited.

[benface]

I think @scope (.group:hover) to (.group) is equivalent to mine, but indeed simpler.

I haven't actually tested it, but I don't think .group:not(:hover) would ever select anything because if an ancestor .group is hovered, wouldn't all descendants also be? (Unless pointer-events: none is used somewhere or something is rendered under or outside the first group somehow.)

[ByteEater-pl]

Yea, it would select something in situations such as you describe, and also when there are no elements matching .group below the hovered one. But it seems after all I actually somewhat misunderstood your use case. Even so, I think it's been a good conversation and we're onto something.

[ByteEater-pl]

Correction: it's not all descendants (perhaps barring pointer-events: none, planned flow-into or other weirdness) of a hovered element that also match :hover, but all ancestors. So it's possible to hover some X inside an element matching .group, making it match .group:hover, and there also being a nested element matching .group which isn't hovered (e.g. a sibling of X).

[benface]

Oh, yeah, brain fart. Thanks for correcting me!