- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2025 23:54:51 +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: Right now, the syntax aorund shadow dom includes a lot of pseudos - ::part(), ::slotted()<br>
<TabAtkins> lea: ::slotted() is probably the easiest to "fix". Bunch of problems with it - can't use querySelector(), can't target descendants<br>
<TabAtkins> lea: I udnerstand this seems desirable to avoid breaking encapsulation.<br>
<TabAtkins> lea: But so many use-cases - wrappers, etc - that need the ability to select past.<br>
<TabAtkins> lea: No way to target siblings of slotted elmeents, their pseudo-elements, etc<br>
<TabAtkins> q+<br>
<TabAtkins> lea: I had thought this was why their styling had low specificity, but that's actually a different issue<br>
<TabAtkins> lea: There's no way to detect slots that have content....<br>
<emilio> q+<br>
<TabAtkins> lea: if "slotted" was a combinator you could use :has()<br>
<TabAtkins> lea: In general, ::slotted() seems like a wart we introduced to get things done quickly, but it causes a lot of problems<br>
<TabAtkins> lea: Ultimately, the relationships between elements is what combinators are for<br>
<TabAtkins> lea: Using pseudo-elements introduces a lot of problems<br>
<TabAtkins> lea: It seems like turning the syntax into a combiantor would solve a lot of problems, even if we have to apply restrictions for now<br>
<TabAtkins> lea: Seems better than piling on more syntax over what pseudo-elements are.<br>
<TabAtkins> lea: We can add more syntax, extend definitions, etc, but ultimately what people need is a combinator.<br>
<emilio> TabAtkins: I think `::part()` has still good justification for its existance<br>
<emilio> ... slotted was indeed kind of a workaround<br>
<emilio> ... I agree if we could do this it'd be good<br>
<TabAtkins> emilio: I think the main restriction that ::slotted() being a pseudo gets you is that arbitrary elements in the light dom can't be targeted by shadow roots<br>
<TabAtkins> emilio: that's a perf consideration<br>
<TabAtkins> emilio: don't wnat to have to look thru arbitrary ancestor chains to know what nodes you need to pull styles from<br>
<TabAtkins> emilio: ::slotted() being a pseudo-element guarantees you that you only need to look at the shadows you're slotted to<br>
<lea> q?<br>
<lea> q+<br>
<astearns> ack TabAtkins<br>
<TabAtkins> emilio: So I think that's a strong justification. I understand the limitations tho.<br>
<emilio> ack emilio<br>
<astearns> ack emilio<br>
<astearns> ack lea<br>
<TabAtkins> lea: I understand it might be tough to do impl-wise due to assumptions made so far.<br>
<TabAtkins> lea: a path forward might be to make it a very restricted combinator at first, syntactigc sugar over the pseudo-element<br>
<TabAtkins> lea: whatever argument you can put inside of ::slotted(), that's all that's allowed after it<br>
<emilio> q+<br>
<TabAtkins> lea: authors then could migrate over to using the new syntax. the longer we wait the more existing CSS we'll have to deal with.<br>
<TabAtkins> lea: so paving the way with a restricted combinator is a way forward<br>
<astearns> ack emilio<br>
<TabAtkins> emilio: I'd lvoe to hear other impl takes<br>
<bramus> q+<br>
<TabAtkins> emilio: this doesn't look like the kind of restrictions you can lift<br>
<TabAtkins> emilio: to figure out how to style a node that's a descendant or sibling of something slotted, you'd need to start arbitrarily walking the ancestor chain to find your closest ancestor that might be slotted<br>
<TabAtkins> emilio: not even clsoest, all of them<br>
<TabAtkins> emilio: I don't think this is the kidn of restriction we can really depend on<br>
<bramus> q-<br>
<astearns> https://github.com/w3c/csswg-drafts/issues/7922#issuecomment-2380098440<br>
<TabAtkins> TabAtkins: ryosuke had some comments<br>
<bramus> scribe+<br>
<bramus> TabAtkins: the usefulness of it as lea listed is taht some of other syntactic parts of css work automatically<br>
<bramus> … all the pseudoe classes and elements of a slotted one would be available<br>
<bramus> emilio: but those already work><br>
<bramus> lea: queryselector will<br>
<lea> s/ lea: queryselector will/ lea: queryselector too/<br>
<bramus> tabAtkins: i dont think you can do ::slotted::before<br>
<bramus> emilio: 99% sure<br>
<bramus> iank_: (missed)<br>
<bramus> TabAtkins: the qs() issue is rather frustrating too<br>
<astearns> s/(missed)/I don’t think our style experts have seen this, but I can ping them/<br>
<bramus> emilio: we would never be able to return textnodes<br>
<bramus> TabAtkins: we dont<br>
<bramus> emilio: (missed)<br>
<lea> q?<br>
<bramus> lea: i have been in csswg meetings where certain things that shipped today that the consensus was that it would never fly<br>
<bramus> … there was a time where :has() was never possible<br>
<bramus> … restrictions on what is impl. change over time<br>
<bramus> … we should not design syntax around current limitations<br>
<bramus> … we can expand it later<br>
<bramus> … we did with nesting<br>
<bramus> … at the time, nesting was designed without lookahead<br>
<astearns> q+<br>
<bramus> … and we designed a syntax that was compatible with unbounded lookahead<br>
<bramus> … and eventually andruud and others had a good idea and it became possible<br>
<bramus> … thats why i think to move to a syntax that would allow the expansions<br>
<emilio> ::slotted() pseudos work afaict: https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/13451<br>
<bramus> … (missed)<br>
<bramus> s/(missed)/adding more warts of what pseudo elements were designed to do<br>
<bramus> … we are using them more and more to represent elements in the DOM<br>
<bramus> … its adding difficulty to learning CSS<br>
<emilio> q+<br>
<bramus> astearns: would push back on that. its not that we cant expand the pseudo syntax but that it would be likelye a one-off thing<br>
<bramus> lea: thats what I am saying<br>
<astearns> ack astearns<br>
<bramus> … ideally its better solved in a way with existing things<br>
<bramus> astearns: it would be still a little werid to have this combinator wher eyou might expect to be able to use it but then learn that there are limitations<br>
<bramus> lea: its a tradeoff<br>
<bramus> emilio: can i push back?<br>
<astearns> ack emilio<br>
<TabAtkins> emilio: push back on some of the things<br>
<TabAtkins> emilio: it feels that turning it into a combiantor without a concrete plan to change the restrictions - it's not making CSS easier<br>
<TabAtkins> emilio: If you have combiantor you can only use at very specific positions - you can't use Nesting, :has(), etc<br>
<TabAtkins> emilio: so I dunno, I just don't feel like this is a meaningful improvement over the status quo<br>
<TabAtkins> emilio: I get the querySelector() point. you'd need to special-case ::slotted() to return elements from another tree, currently qS() never does. But you could make it work.<br>
<TabAtkins> q+<br>
<TabAtkins> emilio: So I don't see this as great answer unless there's a concrete path<br>
<TabAtkins> lea: We didn't have a concrete path for nesting lookahead...<br>
<TabAtkins> emilio: when we ahve a plan, we can go ahead. just don't see it useful until then.<br>
<bramus> TabAtkins: looking over the list of things again, th ecurrent restrctions<br>
<bramus> … some of them have been lfited, not what we can put pseudo after ::slotted is nice<br>
<lea> s/We didn't have a concrete path for nesting lookahead.../We didn't have a concrete path for the north start nesting syntax either when we resolved to get partway there/<br>
<bramus> … if we can fix qs to refer to slotted tha twould fix that part<br>
<bramus> … the specificity one is prolly not compat when we try to fix<br>
<bramus> … we still need has-slotted that you do want to know if there are text nodes in it<br>
<lea> q+<br>
<bramus> … if we just fix queryselector and think about specificity we might be sufficiently fine<br>
<astearns> ack TabAtkins<br>
<bramus> emilio: i dont see the tradeoff to making it a combinator be particularly good<br>
<bramus> lea: either way we go,<br>
<bramus> … if we continue pushing on the syntax we have<br>
<bramus> … there is going to be at least 1 word here<br>
<bramus> … not going to be elegant<br>
<astearns> s/word/wart/<br>
<bramus> ; if we continue pushing on the pseudo-element route, thre is multiple types of weirdness<br>
<bramus> … every DOM api that takes selector must also accept it<br>
<bramus> … if authors want to provide a way for their users, they also have to special case that<br>
<bramus> … and parse selectors on their won<br>
<emilio> q+<br>
<astearns> ack lea<br>
<bramus> … yes, we can special case specificity fixing cascade order is not enough<br>
<bramus> … and who knows what else to special case down the line?<br>
<bramus> … adding more warts to the language<br>
<bramus> … which we have to deal with forever<br>
<bramus> … OTOH if we go combinator route there is only 1 word which we can get rid of later on<br>
<bramus> … for me it seems that the combinator is in favor<br>
<bramus> …when trying to see the big picture<br>
<bramus> … but ymmv<br>
<kbabbitt> s/word/wart/<br>
<emilio> ack fantasai<br>
<TabAtkins> fantasai: two comments. we shoudl keep in mind the experience of the author, so giving them a consistent syntax on a consistent model makes the platform more usable. that's worth doing if it's possible, it's not a no-op even if it seems that way from an engine perspective<br>
<TabAtkins> fantasai: in the distant past we discussed putting elements/combiantors *after* a pseudo-element to indicate that they're processed relative to the pseudo; kinda the pseudo-element is a combinator<br>
<TabAtkins> fantasai: ::region(foo) > a<br>
<astearns> ack emilio<br>
<lea> q+<br>
<TabAtkins> emilio: I'm just not sure I agree that having a combinator ... it won't allow us to remove the pseudo, and a lot of the things you've mentioned work that way with ::slotted() already<br>
<fantasai> s/::region(foo) > a/.foo::nth-fragment(2) a/<br>
<TabAtkins> emilio: a bunch of special cases you need to special case *anyway* because it's a combinator and pointing to a different tree<br>
<TabAtkins> emilio: I'm seeing it's two warts. You have a pseudo-element, and you have ac ombinator, and they both ahve restrictions<br>
<TabAtkins> emilio: like `foo /slotted/ bar { div {...}}` needs to not work<br>
<TabAtkins> lea: you need to invalidate that not at the syntax level, but at selector resolution<br>
<TabAtkins> emilio: right, that's what pseudo-elements do today, it's the same restrictions<br>
<lea> :host: /slotted/ .foo { &.bar { } }<br>
<TabAtkins> lea: that's not possible with pseudo-elements<br>
<TabAtkins> emilio: that's a third new wrinkle<br>
<TabAtkins> lea: not a wrinkle, it's the same as what selectors do today<br>
<TabAtkins> astearns: I dont' think people will be convinced today. Take it back to issue, emilio outline problems with combinator restrictions. We can see how extending querySelector() to allow ::slotted() might look so we can balance things against the proposal.<br>
<TabAtkins> emilio: lea, you asked about pseudo-elements somehow forcing people to parse selectors in content<br>
<TabAtkins> lea: say you have a web component that references other elements. a tooltip for something.<br>
<TabAtkins> lea: either you do IDREF like HTML, or take a selector in an attribute<br>
<TabAtkins> lea: Very useful for libraries to take selectors. There's a mutationObserver wrapper that uses selectors, for instance<br>
<TabAtkins> lea: If we have to special-case certain pseudo-elements, authors also have to do so<br>
<TabAtkins> lea: So I think it's better to have combinators return elements<br>
<TabAtkins> lea: i think it's a good design principle to strive towards<br>
<TabAtkins> emilio: I can buy that. But the pseudo-element isn't going to go away, so authors will need to special-case it anyway.<br>
<TabAtkins> emilio: and they'll need to special-case the /slotted/ as well due to the restrictions<br>
<TabAtkins> astearns: another thing we could ahv eint he issue discussion is whether there is a feasible path to removing the restrictions<br>
<TabAtkins> emilio: yeah, i'm fine *if* we ahve a path to improve this so /slotted/ is a regular combinator, I just dont' see it<br>
<TabAtkins> lea: we don't have to remove all, would probably be easier to let it look into descendants than looking everywhere<br>
<TabAtkins> emilio: not really, sibling would be easier i think<br>
<TabAtkins> emilio: what the browser needs is, giving node X, find all the places rules styling X will come from<br>
<lea> q-<br>
<TabAtkins> emilio: So alan's plan seems reasonable. Figure out what restrictions could be lifted, evaluate from there.<br>
<TabAtkins> astearns: If we do the combinator we dont' have to lard up the pseudo-element<br>
<TabAtkins> astearns: closing this for now, discuss more in issue<br>
<TabAtkins> lea: we also need to listen to the author community, this is something the WC community has been very excited about<br>
<TabAtkins> emilio: I think that's mostly a misunderstanding about the combinator restrictions fixing some things<br>
<TabAtkins> emilio: I think a lot of the demand is based on the combiantor allowing this to work how they want, like it's interleaved with the outer document rules. but that's not how it's going to work.<br>
<TabAtkins> emilio: rules from different trees just don't interleave, they're either fully before or after<br>
<TabAtkins> emilio: I do think that's osmething we want to fix, but that's a separate issue<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-2623196458 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 23:54:52 UTC