[css-values-5] allow specifying flat vs light tree in `sibling-index()` and `sibling-count()`

[argyleink]

In a goal to allow author flexibility with sibling-index() and sibling-count() and the value resolution from the flat tree vs the light tree, I propose adding a parameter to the functions so developers may specify which tree they need. This would allow developers to work with happy path default flat tree default behavior, but when needed they can specify resolution against the light dom.

ul {
  li {
    animation-duration: calc(sibling-index() * 50ms);
  }
}

:host {
  li {
    animation-duration: calc(sibling-index(light-tree) * 50ms);
  }
}

Trade offs:

• it would disrupt the potential for of <<selector>> syntax to be used between the parenthesis
• it would depart from the alignment with nth-child()

Use cases:
I don't really have any example use cases for wanting light tree, but the fact there are two trees to resolve against makes me think eventually someone will show up with a use case 😅

[nt1m]

I don't think we typically expose the tree used to CSS

[lilles]

The current spec saying that sibling-index() / sibling-count() follows the flat tree means it will not correspond with the :nth-* selectors for slotted elements. Is that a behavior we want in the default case? I lean towards having the flat-tree counting as an option.

There is a note in the spec that these function may be extended to accept of <selector>, which would not work on the flat tree. It would be confusing to have a single function work both on flat tree and not at the same time?

[emilio]

FWIW sibling-index and co working on the flat tree by default seems super confusing for authors (CSS uses dom index for virtually everything else).

Whether using the flat tree should be an option I don't have a strong opinion on...

[css-meeting-bot]

The CSS Working Group just discussed [css-values-5] allow specifying flat vs light tree in `sibling-index()` and `sibling-count()` , and agreed to the following:

• RESOLVED: to have sibling-index() and sibling-count() to default to DOM tree

The full IRC log of that discussion

<ydaniv> emilio: this is about which tree do sibling-index and sibling-count work on
<ydaniv> ... right now using the flat tree which is weird default
<ydaniv> ... the right default would probably be the light tree
<ydaniv> ... a lot of work if there is now use-case
<bramus> q+
<ydaniv> ... could expose, but feel strongly default should be DOM tree
<futhark> q+
<astearns> ack bramus
<ydaniv> astearns: this is only about using the DOM tree as default
<ydaniv> bramus: we initially mentioned that this would be whatever n-child is using
<astearns> ack futhark
<ydaniv> futhark: no strong opinion but nth-child already has issues
<ydaniv> ... if we add support selectors inside -index() that would enable it, otherwise there is a clear use-case for using DOM tree
<ydaniv> ... do think it could be said the same for nth-child
<ydaniv> ... there's also a proposal for children-count() and that would have a big difference
<emilio> q+
<ydaniv> ... because if you style the slot ... if allowing flat tree
<astearns> ack emilio
<ydaniv> emilio: I think that makes sense, I think sibling and count <missed>
<ydaniv> ... I could come up with cases for both, we need a more holistic conversation how we expose these in all functions
<ydaniv> ... default should be DOM tree
<bramus> +1
<ydaniv> futhark: I agree
<ydaniv> ... impl.-wise not a big deal for us
<ydaniv> astearns: what if we resolve to change specs to default for DOM tree for sibling-index and -count
<emilio> s/<missed>/sibling and child count for flat tree are a bit more complicated because there are two counts you care about, the one that includes slots and the "flattened" one/
<ydaniv> ... and keep this issue open for swapping for all of other counting functions
<ydaniv> PROPOSED: to have sibling-index() and sibling-count() to default to DOM tree
<ydaniv> RESOLVED: to have sibling-index() and sibling-count() to default to DOM tree