- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 13 Mar 2023 16:03:41 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-shadow-parts] Make `::slotted()` a combinator``. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> lea: ::slotted() is a pseudo-element<br> <TabAtkins> lea: This doesn't really solve author's problems tho<br> <TabAtkins> lea: Four issue in the issue<br> <TabAtkins> lea: Can't use in querySelector<br> <TabAtkins> lea: Can't target children of slotted elements<br> <emilio> q+<br> <TabAtkins> lea: etc, lots because it's just a pseudo-element<br> <TabAtkins> lea: The WC community has chimed in and seem to think making this a combinator would solve these<br> <TabAtkins> lea: ::part() might have a similar approach but is more complicated to avoid exposing too much info, but ::slotted() refers to things in the light dom so it's not exposing anything too bad<br> <TabAtkins> lea: Discussing with fantasai, we don't see any issues spec-wise, but want to hear from impls<br> <castastrophe> q+<br> <TabAtkins> emilio: ::slotted() can also match in the shadow dom, it matches fallback content per spec (but unsure how well that's implemented)<br> <TabAtkins> emilio: Also as-is ::slotted() depends on which shadow tree you're in<br> <Rossen_> ack emilio<br> <TabAtkins> emilio: Also I think we do support ::slotted()::before, etc<br> <TabAtkins> emilio: probably not non-tree-abiding pseudos<br> <TabAtkins> emilio: If we don't support it, we should<br> <TabAtkins> castastrophe: My one concern with adding complexity to ::slotted(), there is already some confusion as to how it's applied<br> <TabAtkins> castastrophe: I have a codepen, like :first-child is first child in the DOM, not based on first in the slot<br> <lea> castastrophe: would love a link to the codepen!<br> <Rossen_> https://codepen.io/castastrophe/pen/rNKjLVj?editors=0010<br> <TabAtkins> castastrophe: So would be useful to clarify how things resolve relative to slot ordering, etc<br> <Rossen_> ack castastrophe<br> <fantasai> TabAtkins: I feel like that might be the reason we ended up designing ::slotted() the way it is, because you *can't* have sibling relationships<br> <fantasai> TabAtkins: unless it's a little more clear what context it's evaluated it<br> <fantasai> TabAtkins: but the rest of the issues lea brings up seem to be accidental damage<br> <lea> q+<br> <fantasai> TabAtkins: Not being able to descend into slotted element, no reason not to allow that<br> <castastrophe> Referenced codepen: https://codepen.io/castastrophe/pen/yLXpagw<br> <fantasai> lea: The point emilio brought up is good, that sometimes these elements can also be in the shadow DOM<br> <Rossen_> ack lea<br> <fantasai> lea: what if the slotted combinator didn't match such fallback content, only the author-provided elements<br> <fantasai> lea: but not sure if it satisfies the use cases, something to thin about<br> <TabAtkins> lea: I wonder if /slotted/ not matching fallback content would make sense. Not sure if it would still satisfy use-cases tho<br> <fantasai> TabAtkins: If you did want to distinguish other proposal to haveing a pseudo-class for whether using fallback content or not<br> <fantasai> TabAtkins: :has-slotted or something?<br> <TabAtkins> castastrophe: I think named slots is a bit of a challenge, what does light dom look like in multiple named slots<br> <lea> I think you can style fallback content with regular shadow DOM CSS, so it doesn't seem to be much of a problem at first glance?<br> <TabAtkins> castastrophe: The codepen does show the confusion about the elements having a relationship in the light dom vs in the slots<br> <lea> q?<br> <lea> q+<br> <Rossen_> ack lea<br> <TabAtkins> lea: I think you can style fallback content with regular CSS in the shadow.<br> <fantasai> TabAtkins: Emilio, you said that the ::slotted selector can match differently dependingon which shadow tree it's coming from, what did you mean?<br> <castastrophe> q+<br> <TabAtkins> fantasai: So frist thing to tink about is, if we add this, would we use the slotted relationship or the light dom relationship<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: I think using the slotted relationship would be more understandable but not sure<br> <fantasai> lea: explain?<br> <fantasai> TabAtkins: Say you're slotting all the even elements<br> <fantasai> TabAtkins: and you asked :nth-child(2)<br> <fantasai> TabAtkins: is this the 2nd slotted item, or the 2nd item in the original DOM?<br> <fantasai> lea: we'd need to figure out what the author expectations are<br> <emilio> q+<br> <fantasai> TabAtkins: I expect there's complexity in evaluating on the slotted list<br> <TabAtkins> lea: Intuitively to me, as an author, it seems like the light dom relationship makes more sense<br> <fantasai> lea: intuitively as an author, it seems to me the light DOM relationships makes more sense<br> <fantasai> TabAtkins: Wanting to style first/last items in the slot using :first-child/:last-child is reasonable case<br> <lea> q+<br> <Rossen_> ack castastrophe<br> <fantasai> castastrophe: There's a lot of confusion over named slots<br> <fantasai> castastrophe: e.g. if you pull things into named slots, currently :first-child is only if it's the first child in the light DOM<br> <fantasai> castastrophe: but not if it's the first child in the slot<br> <fantasai> castastrophe: I think we'd need to be very clear in the spec<br> <fantasai> scribnick: fantasai<br> <fantasai> scribenick: fantasai<br> <Rossen_> ack emilio<br> <fantasai> emilio: Regarding what we talked before, matching where the selector is<br> <fantasai> emilio: in the case of nested slots, it woudl jump across to slots in the current shadow tree<br> <fantasai> emilio: that's the behavior I was talkinga bout before<br> <fantasai> castastrophe: if you have a slot that's passing content to a shadow template that also has.. if you have multiple?<br> <fantasai> emilio: from outer tree, slotted pseudo would cross that nested slot<br> <fantasai> emilio: the outer shadow tree<br> <fantasai> emilio: so you could still style the slotted contents ...<br> <fantasai> emilio: I need a whiteboard to reason about nested slots!<br> <fantasai> emilio: but I'm sure we jump across to the right scope<br> <fantasai> emilio: that scope is dependent on the tree that we're looking at right now<br> <fantasai> Rossen_: I'm hoping that made sense to you, Tab?<br> <castastrophe> q+<br> <fantasai> TabAtkins: I don't know that's necessarily right...<br> <fantasai> TabAtkins: I'd have to look up again the slot assignment algo<br> <fantasai> TabAtkins: I forget, if you're in nested slot, if we match the slot element from higher up or the things slotted in that element<br> <TabAtkins> Oh, it's after flattening<br> <Rossen_> ack fantasai<br> <TabAtkins> the elements can def come from multiple trees tho<br> <TabAtkins> q+<br> <fantasai> fantasai: I think we definitely need ability to style based on the slotted relationships<br> <fantasai> fantasai: as brought up before<br> <fantasai> fantasai: if you're pulling a subset of items into a slot, e.g. into a list<br> <Rossen_> Zakim, close queue<br> <Zakim> ok, Rossen_, the speaker queue is closed<br> <fantasai> florian: and you want to style every other item with :nth-child(), you want to get every other slotted item<br> <fantasai> s/florian/fantasai/<br> <fantasai> fantasai: not a random set of items based on what was selected or not from the light DOM<br> <fantasai> fantasai: similarly, as was brought up earlier for first/last child styling<br> <bkardell_> hmm<br> <TabAtkins> fantasai: We might also want the original light dom relationship<br> <TabAtkins> fantasai: But definitely think we need based on the slotted relationship<br> <bkardell_> Does that not imply that you know something about the dom inside the shadow root then?<br> <TabAtkins> fantasai: Since ::slotted() currently works based on light dom, one possibility would have ::slotted stay with that, but /slotted/ shift into "the slotted view of the world"<br> <TabAtkins> fantasai: we've discussed different ways to shift your view of the world<br> <bkardell_> Rossen_: yeah?<br> <fantasai> s/world/world, one of which was using subtrees under pseudo-elements<br> <fantasai> lea: there are two relationships, one based on relationships in light dom or slotted tree<br> <fantasai> lea: is one ??? the other?<br> <TabAtkins> lea: There's these two behavior - based on light dom, based on slotting - is one much easier to implement?<br> <fantasai> s/???/easier to implement than/<br> <fantasai> Rossen_: Does anyone have an answer?<br> <fantasai> emilio: slotted thing is new thing, so you need to somehow decide on ?? child matching vs<br> <fantasai> emilio: other thing is storage of slotted children different<br> <fantasai> Rossen_: sounds like light DOM is easier<br> <bkardell_> q+<br> <fantasai> emilio: but probably not impossible to make slotted work<br> <Rossen_> ack lea<br> <Rossen_> ack castastrophe<br> <fantasai> castastrophe: I agree, I think light DOM would be less complex<br> <fantasai> castastrophe: because that relationship is flat<br> <lea> Light DOM is easier to implement because that's the current behavior of ::slotted(), but does anyone have any feel of the implementability of the other option?<br> <fantasai> castastrophe: I was just making notation, but I think the nested shadow DOM is getting the slot element, not the slotted content<br> <fantasai> castastrophe: it renders it correctly, but when using CSS selectors<br> <fantasai> castastrophe: you don't have access to the slotted content until further down<br> <fantasai> castastrophe: So I think it's just the tag <slot> in nested shadows<br> <fantasai> castastrophe: so I think we need to open a new issue for how we build styles for named combinators<br> <fantasai> castastrophe: need to identify the named slot and the combinator in the same query<br> <emilio> I need to check what this `while` loop is doing then: https://searchfox.org/mozilla-central/rev/af78418c4b5f2c8721d1a06486cf4cf0b33e1e8d/servo/components/selectors/matching.rs#464-468<br> <Rossen_> ack TabAtkins<br> <fantasai> TabAtkins: So Cas, if you've been seeing the slot element matched by ::slotted in deeply nested situations, that is spec violation<br> <fantasai> TabAtkins: because should flatten and get the real elements<br> <fantasai> TabAtkins: so the slotted inside the nested part should see the original light dom elements, not the slot<br> <fantasai> Rossen_: It sounds like we'll end issue without a concrete resolution<br> <fantasai> Rossen_: let's pick it up again on Wednesday<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7922#issuecomment-1466432586 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 13 March 2023 16:03:43 UTC