- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2025 19:50:00 +0000
- To: public-css-archive@w3.org
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`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> oriol: Cuirrently spec says when you use sibling-index()/count() on pseudo-element, it refers to the ultimate originating element<br>
<TabAtkins> oriol: this seems confusing for things like ::slotted(), because they point to a real element<br>
<TabAtkins> oriol: seems werid<br>
<TabAtkins> oriol: For things like ::before/after, could be more reasonble to use an index smaller/larger than the real children<br>
<TabAtkins> oriol: Tho defining it this way could be hard<br>
<TabAtkins> oriol: Proposal in the issue is to let the function accept a selector, and it provides an index among matching elements<br>
<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)<br>
<bramus> q+<br>
<TabAtkins> oriol: think this might be self-consistent and useful<br>
<TabAtkins> oriol: Emilio also mentioned ::part()<br>
<emilio> q+<br>
<TabAtkins> oriol: ideas?<br>
<TabAtkins> q+<br>
<astearns> ack bramus<br>
<TabAtkins> bramus: Using sibling-index() on ::before/::after doesn't really make sense? That's why we used the index from the orignating element<br>
<TabAtkins> oriol: Are you asserting it doesn't make sense, or asking?<br>
<kizu> q+<br>
<TabAtkins> bramus: Don't think it makes sense to have to return something on those.<br>
<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<br>
<TabAtkins> oriol: It avoids tying it to the ultimate originating element, which fixes ::part()/::slotted()<br>
<TabAtkins> bramus: side question, do we have parity with the :nth-child() numbers?<br>
<TabAtkins> TabAtkins: yup, same 1-indexing<br>
<TabAtkins> bramus: If you have an element matched by :nth-child(3), and slot it, would it get 3 from sibling-index()?<br>
<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<br>
<astearns> ack emilio<br>
<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<br>
<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?<br>
<TabAtkins> emilio: But yeah, I think we need some way to say the index of an element isn't exposed.<br>
<TabAtkins> emilio: fantasai did bring up the use-case for ::marker or ::before referring to the originating element is pretty clear<br>
<TabAtkins> (similar to using counters)<br>
<fantasai> ::before { content: "Item " sibling-index() " of " sibling-count(); }<br>
<TabAtkins> emilio: But yeah we need a clear distinction between generated pseudos, part-like pseudos, and ::part() and ::slotted() specifically<br>
<astearns> ack TabAtkins<br>
<emilio> TabAtkins: Agree that for ::before / ::marker, deferring to originating element has some good cases<br>
<bramus> TabAtkins: I agree that for before and marker deferring to the originating element has good use cases<br>
<emilio> ... also that we don't want to expose them for ::part()<br>
<bramus> … for part we dont, for th esame reason … dont expose underlying dom structure<br>
<emilio> ... for ::slotted() seems fine<br>
<bramus> … for slotted perfectly fine, that is not intentially hidden info<br>
<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<br>
<bramus> … does that make it difficult for part or ???<br>
<bramus> s/???/or are styles given toa part kept separately<br>
<bramus> emilio: as an impl detail they get stored espearetly bc you look them up separately<br>
<bramus> … but the weird thing is that you could have a rule like<br>
<emilio> div, :host::part(foo) { ... }<br>
<astearns> s/espearetly/separately<br>
<bramus> … they could both match<br>
<bramus> … and its weird to have that do a diff thing<br>
<bramus> … suggestiont look at the tree where the rules come from<br>
<bramus> … you need to know the identifer stuff and that is more reasonable thing to use rather than whcih selector hahppened to match<br>
<bramus> TabAtkins: agree<br>
<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<br>
<bramus> … in same tree is fine<br>
<bramus> … if its the inverse when styles are coming froma lower shadow than the el like slotted<br>
<bramus> … then its also fine<br>
<bramus> emilio: so dbaron metnioned being concerned to carry that info<br>
<bramus> … we already to that for some info eg global names<br>
<bramus> … for example font-family in shadow tree - need so know where the value came from<br>
<bramus> dbaron: i think noamr knows how that works<br>
<astearns> ack kizu<br>
<TabAtkins> kizu: +1 to using originating element for ::before/after<br>
<TabAtkins> kizu: might be some use-cases for siblings of ::after<br>
<kizu> https://github.com/w3c/csswg-drafts/issues/11068<br>
<TabAtkins> kizu: that's a separate proposal i've made<br>
<TabAtkins> kizu: children-count() rather than sibling-count()<br>
<TabAtkins> kizu: But this would cover the use-case where you have ::after participate as a sibling<br>
<TabAtkins> kizu: But generally just using th eoriginating element for the sibling count makes sense<br>
<TabAtkins> q+<br>
<astearns> ack TabAtkins<br>
<bramus> TabAtkins: utlimately the part info hiding is kinda just best effort<br>
<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<br>
<bramus> ntim: waht does real sibling count mean><br>
<bramus> TabAtkins: the part lives in a tree<br>
<bramus> ntim: does it include shadow siblings><br>
<bramus> emilio: yes<br>
<bramus> TabAtkins: we expose some bits of the shadow structure anyway, worst case inehrientace does. this is all best effort<br>
<bramus> … we want to reduce the dependence on structure authors hsouldn not rely on<br>
<bramus> emilio: i’d prefer not exposing it<br>
<bramus> ntim: same<br>
<bramus> astearns: i think we have consensus on an aspirational consensus<br>
<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<br>
<bramus> astearns: so only change is for part<br>
<bramus> TabAtkins: part-like pseudos<br>
<bramus> ntim: if we modify treeo f pseudos to add a new pseudos, that would break?<br>
<bramus> TabAtkins: only referring to part-like which have a real element backing them<br>
<bramus> … not the other pseudos<br>
<bramus> ntim: so always be 1?<br>
<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<br>
<bramus> ntim: what is the relation with part-like pseudos?<br>
<bramus> TabAtkins: spec right now says any pseudo<br>
<bramus> … to refer to the original element<br>
<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<br>
<bramus> ntim: so only slotted changes?<br>
<bramus> emilio: no, we need to decied what exactly gets returned when we hide it<br>
<bramus> … 0 is fine<br>
<bramus> TabAtkins: yeah, something<br>
<bramus> emilio: that is changing<br>
<bramus> … slotted also changes<br>
<bramus> … and before, after, marker don}t change<br>
<bramus> … but this is not shipping so fine<br>
<bramus> ntim: for all part-like pseudos we return 0?<br>
<bramus> TabAtkins: no, depends on the tree position of the style and the element being styled<br>
<bramus> … so if th eprop comes from a higher tree the eleme is in a deepr shadow tree we suppress<br>
<bramus> … other way around its fine and we expos that<br>
<astearns> ack dbaron<br>
<bramus> dbaron: i think we wantt o allow it through only if styles come from the same or descendant scope<br>
<bramus> TabAtkins: YES<br>
<bramus> dbaron: distinction between element scope and any descendant scopes which allow the index vs all other scopes that hide it<br>
<bramus> emilio: agree<br>
<bramus> ntim: so what if you use it on details-content<br>
<bramus> TabAtkins: gets hidden, real element<br>
<bramus> emilio: ???<br>
<bramus> TabAtkins: details-content is identical to a part<br>
<bramus> astearns: so we have consensus that the current spec …<br>
<bramus> TabAtkins: current spec is fine for non-part-like pseudos<br>
<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<br>
<bramus> astearns: and if that is not the case?<br>
<bramus> TabAtkins: zero or IACVT or sth like that<br>
<dbaron> (and we're sure "not the case" shouldn't be "like other pseudos"?)<br>
<bramus> astearns: other questions about this?<br>
<TabAtkins> might be<br>
<bramus> dbaron: what was reasoning for not falling back to behavior for other pseudos where we dont expose?<br>
<bramus> emilio: potentialy multiple hosts, bu tits tricky<br>
<bramus> TabAtkins: use the utlimate originaating element<br>
<bramus> TabAtkins: oh, but that depends on the selector<br>
<bramus> dbaron: yes, tricky<br>
<bramus> astearns: objects to resolving?<br>
<bramus> s/objects/objections<br>
<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<br>
<bramus> TabAtkins: element-backed pseudos instead of part-like<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9573#issuecomment-2622696411 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 January 2025 19:50:01 UTC