[css-values] Pseudo-elements shouldn't defer sibling-index() and sibling-count() to its ultimate originating element

[Loirooriol]

There is a conflict when a pseudo-element is also a full fledged element. For example,

slot::slotted(*) {
  z-index: sibling-index();
}

should probably use the index of the slotted elements, not the index of the slot where they are slotted.

Even in more normal cases like ::after, I tend to think authors would prefer sibling-index() to be the number of children of the originating element + 1 rather than the index of the originating element. Though this seems complex in general, so rather than providing a surprising value, it's probably better to handle it as an error just like #9572 will handle non-matching elements.

That is, we would default sibling-index() to use a *|* selector, and then when used on an ::after, it won't match, so just treat this consistently with #9572. But sibling-index(::after) would match, so we would get 1. For simplicity, I guess we could say that pseudo-elements that aren't full fledged elements aren't considered to have siblings.

[emilio]

::part() is also fun, because I don't think we generally want to expose the index that way?

[css-meeting-bot]

The CSS Working Group just discussed [css-values] Pseudo-elements shouldn't defer sibling-index() and sibling-count() to its ultimate originating element, and agreed to the following:

• RESOLVED: only expose sibling info for part-like pseudos if the style is coming from the same or a descendant tree scope of the element

The full IRC log of that discussion

<TabAtkins> oriol: Cuirrently spec says when you use sibling-index()/count() on pseudo-element, it refers to the ultimate originating element
<TabAtkins> oriol: this seems confusing for things like ::slotted(), because they point to a real element
<TabAtkins> oriol: seems werid
<TabAtkins> oriol: For things like ::before/after, could be more reasonble to use an index smaller/larger than the real children
<TabAtkins> oriol: Tho defining it this way could be hard
<TabAtkins> oriol: Proposal in the issue is to let the function accept a selector, and it provides an index among matching elements
<TabAtkins> oriol: If missing, assuming a `*` selector, so pseudos don't match (and we'd use the current spec behavior when used *on* a pseudo-element)
<bramus> q+
<TabAtkins> oriol: think this might be self-consistent and useful
<TabAtkins> oriol: Emilio also mentioned ::part()
<emilio> q+
<TabAtkins> oriol: ideas?
<TabAtkins> q+
<astearns> ack bramus
<TabAtkins> bramus: Using sibling-index() on ::before/::after doesn't really make sense? That's why we used the index from the orignating element
<TabAtkins> oriol: Are you asserting it doesn't make sense, or asking?
<kizu> q+
<TabAtkins> bramus: Don't think it makes sense to have to return something on those.
<TabAtkins> oriol: so one idea is that if the elemnt doesn't match the provided selector, it's IACVT, so that would match the "doesn't make sense" part
<TabAtkins> oriol: It avoids tying it to the ultimate originating element, which fixes ::part()/::slotted()
<TabAtkins> bramus: side question, do we have parity with the :nth-child() numbers?
<TabAtkins> TabAtkins: yup, same 1-indexing
<TabAtkins> bramus: If you have an element matched by :nth-child(3), and slot it, would it get 3 from sibling-index()?
<TabAtkins> oriol: There's another issue about whether it counts in the light tree or flat tree, I think that's what you are questioning
<astearns> ack emilio
<TabAtkins> emilio: I brought up ::part() because I think we don't want to expose the DOM structure of parts. I think for ::slotted() it's probably fine ot use the real index of the element
<TabAtkins> emilio: But yeah, unsure how we want to do it. Making a value depend on the selector used is weird.... maybe tie it to the tree the style and element are in?
<TabAtkins> emilio: But yeah, I think we need some way to say the index of an element isn't exposed.
<TabAtkins> emilio: fantasai did bring up the use-case for ::marker or ::before referring to the originating element is pretty clear
<TabAtkins> (similar to using counters)
<fantasai> ::before { content: "Item " sibling-index() " of " sibling-count(); }
<TabAtkins> emilio: But yeah we need a clear distinction between generated pseudos, part-like pseudos, and ::part() and ::slotted() specifically
<astearns> ack TabAtkins
<emilio> TabAtkins: Agree that for ::before / ::marker, deferring to originating element has some good cases
<bramus> TabAtkins: I agree that for before and marker deferring to the originating element has good use cases
<emilio> ... also that we don't want to expose them for ::part()
<bramus> … for part we dont, for th esame reason … dont expose underlying dom structure
<emilio> ... for ::slotted() seems fine
<bramus> … for slotted perfectly fine, that is not intentially hidden info
<bramus> … so emilio you said it is tricky and weir dto have a value of a fn return a value depending on how you selected it
<bramus> … does that make it difficult for part or ???
<bramus> s/???/or are styles given toa part kept separately
<bramus> emilio: as an impl detail they get stored espearetly bc you look them up separately
<bramus> … but the weird thing is that you could have a rule like
<emilio> div, :host::part(foo) { ... }
<astearns> s/espearetly/separately
<bramus> … they could both match
<bramus> … and its weird to have that do a diff thing
<bramus> … suggestiont look at the tree where the rules come from
<bramus> … you need to know the identifer stuff and that is more reasonable thing to use rather than whcih selector hahppened to match
<bramus> TabAtkins: agree
<bramus> … if the style if coming form a higher tree than the el its on it would not work, as part would not expose antyhthing
<bramus> … in same tree is fine
<bramus> … if its the inverse when styles are coming froma lower shadow than the el like slotted
<bramus> … then its also fine
<bramus> emilio: so dbaron metnioned being concerned to carry that info
<bramus> … we already to that for some info eg global names
<bramus> … for example font-family in shadow tree - need so know where the value came from
<bramus> dbaron: i think noamr knows how that works
<astearns> ack kizu
<TabAtkins> kizu: +1 to using originating element for ::before/after
<TabAtkins> kizu: might be some use-cases for siblings of ::after
<kizu> https://github.com//issues/11068
<TabAtkins> kizu: that's a separate proposal i've made
<TabAtkins> kizu: children-count() rather than sibling-count()
<TabAtkins> kizu: But this would cover the use-case where you have ::after participate as a sibling
<TabAtkins> kizu: But generally just using th eoriginating element for the sibling count makes sense
<TabAtkins> q+
<astearns> ack TabAtkins
<bramus> TabAtkins: utlimately the part info hiding is kinda just best effort
<bramus> … if too much trouble to try and hide that base on style vs eleme origin, i think its fine to expose the true sibling-* for a part element
<bramus> ntim: waht does real sibling count mean>
<bramus> TabAtkins: the part lives in a tree
<bramus> ntim: does it include shadow siblings>
<bramus> emilio: yes
<bramus> TabAtkins: we expose some bits of the shadow structure anyway, worst case inehrientace does. this is all best effort
<bramus> … we want to reduce the dependence on structure authors hsouldn not rely on
<bramus> emilio: i’d prefer not exposing it
<bramus> ntim: same
<bramus> astearns: i think we have consensus on an aspirational consensus
<bramus> TabAtkins: proposal is to continue to use current spec text sfor most pseudos. for part-like ones we conditioanlly expose or not the real index based on the relative ordering of the trees so that part does not expose but slotted does
<bramus> astearns: so only change is for part
<bramus> TabAtkins: part-like pseudos
<bramus> ntim: if we modify treeo f pseudos to add a new pseudos, that would break?
<bramus> TabAtkins: only referring to part-like which have a real element backing them
<bramus> … not the other pseudos
<bramus> ntim: so always be 1?
<bramus> TabAtkins: no, if you used slotted to select and then you use sibling-index in a prop it gets the actual index of the slotted element, as if you were selecting the element normally
<bramus> ntim: what is the relation with part-like pseudos?
<bramus> TabAtkins: spec right now says any pseudo
<bramus> … to refer to the original element
<bramus> … this would change it so that in the slotted case you get th eslotted element’s index but part would ocntinue to hide it
<bramus> ntim: so only slotted changes?
<bramus> emilio: no, we need to decied what exactly gets returned when we hide it
<bramus> … 0 is fine
<bramus> TabAtkins: yeah, something
<bramus> emilio: that is changing
<bramus> … slotted also changes
<bramus> … and before, after, marker don}t change
<bramus> … but this is not shipping so fine
<bramus> ntim: for all part-like pseudos we return 0?
<bramus> TabAtkins: no, depends on the tree position of the style and the element being styled
<bramus> … so if th eprop comes from a higher tree the eleme is in a deepr shadow tree we suppress
<bramus> … other way around its fine and we expos that
<astearns> ack dbaron
<bramus> dbaron: i think we wantt o allow it through only if styles come from the same or descendant scope
<bramus> TabAtkins: YES
<bramus> dbaron: distinction between element scope and any descendant scopes which allow the index vs all other scopes that hide it
<bramus> emilio: agree
<bramus> ntim: so what if you use it on details-content
<bramus> TabAtkins: gets hidden, real element
<bramus> emilio: ???
<bramus> TabAtkins: details-content is identical to a part
<bramus> astearns: so we have consensus that the current spec …
<bramus> TabAtkins: current spec is fine for non-part-like pseudos
<bramus> … for part-like pseudos we only expose sibling info if the style is coming from the same or a descendant tree scope of the element
<bramus> astearns: and if that is not the case?
<bramus> TabAtkins: zero or IACVT or sth like that
<dbaron> (and we're sure "not the case" shouldn't be "like other pseudos"?)
<bramus> astearns: other questions about this?
<TabAtkins> might be
<bramus> dbaron: what was reasoning for not falling back to behavior for other pseudos where we dont expose?
<bramus> emilio: potentialy multiple hosts, bu tits tricky
<bramus> TabAtkins: use the utlimate originaating element
<bramus> TabAtkins: oh, but that depends on the selector
<bramus> dbaron: yes, tricky
<bramus> astearns: objects to resolving?
<bramus> s/objects/objections
<bramus> RESOLVED: only expose sibling info for part-like pseudos if the style is coming from the same or a descendant tree scope of the element
<bramus> TabAtkins: element-backed pseudos instead of part-like