- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Sep 2024 23:44:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-shadow-parts][css-scoping] Is ::slotted() allowed after ::part()?`, and agreed to the following: * `RESOLVED: don't allow ::slotted after ::part` <details><summary>The full IRC log of that discussion</summary> <dholbert> dbaron: this is the last one of these<br> <dholbert> dbaron: is ::slotted allowed after ::part?<br> <dholbert> dbaron: this only makes sense if a shadow DOM exposes a slot as a part<br> <dholbert> lea: I've done that<br> <dholbert> dbaron: ok. So it sounds like this is maybe a useful thing to do sometimes<br> <emilio> q+<br> <dholbert> lea: that's useful when you want to expose a part but you don't want to pay a separate container for it. It can become a box. why not expose it<br> <dholbert> dbaron: So, the current state of allowing ::slotted after ::part is that Chromium and Gecko do not allow it<br> <dholbert> dbaron: WebKit allows it at parse time but it doesn't match the things I thought it should match<br> <dholbert> dbaron: there are 2 points here.<br> <dholbert> dbaron: (1) it's not clear to me if there's much of a use-case for ::slotted after ::part<br> <dholbert> dbaron: (2) it's pretty complex to implement<br> <lea> q+<br> <dholbert> dbaron: it's combining things that jump in/out of shadow trees in ways that are extra fun and raise questions about how to cascade rules from different sources<br> <dholbert> dbaron: general rules suggest that this should be allowed, but it's a good bit of work to do correctly, and it's not clear to me if there are actually good use-cases for it<br> <dholbert> dbaron: and if it would require rewriting a bunch of scary code in the middle of cascade impl to do something obscure that nobody needs<br> <Rossen6> ack emilio<br> <dholbert> emilio: I was going to say what dbaron just said<br> <dholbert> emilio: I'm pretty sure the reason this doesn't work in webkit is:<br> <dholbert> emilio: when youre styling a slotted node, you look at the trees from the shadow-trees where you're slotted (?)<br> <dholbert> emilio: the slotted combination makes it go out of the trees you would usually look at, which is why it doesn't work<br> <dholbert> emilio: this doesn't seem useful. I'd rather not allow it, & agree with dbaron<br> <RRSAgent> ok, fantasai; I will not start a new log at midnight<br> <dholbert> lea: the use-case for me was for a wrapper that's there whether you have the fallback content display or not<br> <dholbert> lea: doing that with a nested element... you have to wrap the slot with a separate element... I suppose that'd work<br> <dholbert> lea: there was a reason, but I need to remember it<br> <keithamus> q+<br> <dholbert> dbaron: it's not just about why did you want to expose a slot as a part, but: if you did that, would you want to use ::part::slotted _from outside_<br> <Rossen6> ack lea<br> <dholbert> emilio: there are use cases for exposing slots as parts, thats's what the details element ended up doing<br> <dholbert> emilio: but the question is why would you do details::slotted::div (?) instead of details>div<br> <Rossen6> ack keithamus<br> <emilio> s/details::slotted::div/details::details-content::slotted(div)/<br> <dholbert> keithamus: for something to be slotted, you can query for it... the only thing you gain from ::slotted on the outside is to know that it's a descendant of a named ::part. but I can't see why that would matter in practice<br> <dholbert> keithamus: it kind of exposes an impl detail of the shadow dom that might be undesirable<br> <emilio> q+<br> <dholbert> keithamus: would you have to make it unmatchable in a closed shadow root?<br> <Rossen6> ack emilio<br> <dholbert> emilio: we resolved to add :has(:slotted) , so that detail would already be exposed via that pseudo-class<br> <dholbert> keithamus: good point, maybe we should ???<br> <lea> s/:has(:slotted)/:has-slotted/<br> <emilio> s/:has(:slotted)/:has-slotted/<br> <dholbert> dbaron: even though it's a closed shadow-root, it's exposed as a part. there's supposed to be something exposed there<br> <lea> q+ to say, it's definitely not high priority. Q: if we decide to not allow it now, is that something we can revisit later or will we run into web compat?<br> <dholbert> emilio: in general we haven't gone very far on trying to prevent exposing pseudo-classes/elements that are dependent on what element the part is<br> <dholbert> emilio: some are useful. you can do ::part ::placeholder to style a placeholder - that's an actual thing that was requested<br> <dholbert> emilio: I'm not sure we should go to great lengths to avoid matching ::has(::slotted)<br> <dholbert> er :has-slotted<br> <emilio> s/::has(::slotted)/:has-slotted after ::part()<br> <dholbert> lea: if we decide not to do it, can we revisit this in the future?<br> <dholbert> lea: or will we be hit by webcompat in that scenario?<br> <emilio> +1 to dbaron<br> <dholbert> dbaron: always some risk of webcompat problems. Maybe there already are webcompat problems. But I think this is in the category of low-risk, and we could allow it in the future even if we don't do it now. But not a thing we can promise<br> <fantasai> +1 to dbaron<br> <dholbert> dbaron: and I can't even really promise that we can do it now<br> <dholbert> Proposed resolution: don't allow ::slotted after ::part<br> <dholbert> RESOLVED: don't allow ::slotted after ::part<br> <lea> When do we reconvene?<br> <astearns> lea: 7 minutes ago officially, but I am guessing 5-10 minutes from now<br> <keithamus> We are reconvening<br> <emilio> scribe+<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10807#issuecomment-2380290387 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 September 2024 23:44:35 UTC