[css-values] Extend sibling-index() and sibling-count() with a selector argument

[Loirooriol]

https://drafts.csswg.org/css-values-5/#tree-counting

So sibling-count(<selector>) would count the number of inclusive siblings that match the selector.

And sibling-index(<selector>) would provide the index of the element among its inclusive siblings that match the selector. If the element doesn't match the selector, I guess this could be zero? Or maybe become invalid at computed-value time or something.

[Que-tin]

Thought about this a couple of times as well. Really like this approach, looks like it covers all edge cases or at least provides a got solution to work around these.

[kizu]

This is something I'd really want to have, and I encountered a few places where it could be very helpful while working on my latest article.

In https://github.com/w3c/csswg-drafts/issues/11069 @nt1m asked:

How does this work with shadow DOM / slotted content?

I think this is something that should be decided generally for any selectors as values, and I'll copy my comment from there:

It would need to work consistently with, but I can see how this can be a complex issue, as I don't think we handled selectors inside values before, so it is tricky to define how they should work across boundaries.

Like, my first intuition is to make it work the same other selectors work: if it is defined in the light DOM, then it should only select light DOM stuff, and vice versa. But that means that the selector itself will need to somehow be coupled with its origin, as the value itself could be inherited across the boundaries.

[Loirooriol]

I guess the shadow DOM question applies regardless of this issue.