Skip to content

[css-shadow-parts][css-scoping] Is ::slotted() allowed after ::part()? #10807

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
dbaron opened this issue Aug 30, 2024 · 3 comments
Open

[css-shadow-parts][css-scoping] Is ::slotted() allowed after ::part()? #10807

dbaron opened this issue Aug 30, 2024 · 3 comments
Labels
css-scoping-1 Current Work css-shadow-parts-1 Needs Edits

Comments

@dbaron
Copy link
Member

dbaron commented Aug 30, 2024

The ::part spec says that all pseudo-elements are allowed after ::part(). This includes ::slotted(), although it's a bit difficult to make it work, and it's not clear to me that it's useful.

Gecko and Chrome currently don't accept ::slotted() after ::part() (also see #10786). WebKit does, but it doesn't appear to match in cases where I think it ought to (if I'm doing it right!).

See this testcase, where my theory is that all of the border, color, and background styles should work:

<!DOCTYPE HTML>
<style>
  #host::part(main) { display: block; border: medium solid green; }
  #host::part(main)::slotted(.item) { background: lime }
</style>
<div id="host">
  <template shadowrootmode="open">
    <style>
      slot[part="main"]::slotted(.item) { color: orange }
    </style>
    <slot part="main"></slot>
  </template>
  <p class="item">One</p>
</div>

Should this work?

(The "is it syntactically valid" aspects of this decision, pending #10786, also apply to part-like pseudo-elements, although it probably would never work for any of them.)
@astearns astearns moved this to TPAC/FTF agenda items in CSSWG Agenda TPAC 2024 Sep 13, 2024
@tabatkins
Copy link
Member

Hm. So, ::slotted() is a shadowish variant of the child combinator; it selects children in the flat tree, more or less. Since we don't allow ::part() > .foo, then, I'm inclined to say it's consistent to ban ::part()::slotted(.foo) as well.

On the other hand, the shadow author has control over the subtree and can choose to expose the part's children as more parts if they want; they don't have control over the slotted elements. So I could see an argument that it's potentially useful to expose this. A similar argument can be made that "children of an element" are structural information that the component author can reasonably not want to expose (thus, we don't), but "elements slotted into this slot" are morally much closer to a property of the slot element, since the component author isn't in control of them.

I think that means I'm torn and can go either way on this issue.

@LeaVerou
Copy link
Member

Given that we keep getting feedback that the current styling encapsulation is too draconian, I'd be inclined to allow ::slotted() after ::part(), and I believe I’ve encountered use cases that genuinely needed it.

@LeaVerou LeaVerou mentioned this issue Sep 24, 2024
Open
@css-meeting-bot
Copy link
Member

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
The full IRC log of that discussion <dholbert> dbaron: this is the last one of these
<dholbert> dbaron: is ::slotted allowed after ::part?
<dholbert> dbaron: this only makes sense if a shadow DOM exposes a slot as a part
<dholbert> lea: I've done that
<dholbert> dbaron: ok. So it sounds like this is maybe a useful thing to do sometimes
<emilio> q+
<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
<dholbert> dbaron: So, the current state of allowing ::slotted after ::part is that Chromium and Gecko do not allow it
<dholbert> dbaron: WebKit allows it at parse time but it doesn't match the things I thought it should match
<dholbert> dbaron: there are 2 points here.
<dholbert> dbaron: (1) it's not clear to me if there's much of a use-case for ::slotted after ::part
<dholbert> dbaron: (2) it's pretty complex to implement
<lea> q+
<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
<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
<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
<Rossen6> ack emilio
<dholbert> emilio: I was going to say what dbaron just said
<dholbert> emilio: I'm pretty sure the reason this doesn't work in webkit is:
<dholbert> emilio: when youre styling a slotted node, you look at the trees from the shadow-trees where you're slotted (?)
<dholbert> emilio: the slotted combination makes it go out of the trees you would usually look at, which is why it doesn't work
<dholbert> emilio: this doesn't seem useful. I'd rather not allow it, & agree with dbaron
<RRSAgent> ok, fantasai; I will not start a new log at midnight
<dholbert> lea: the use-case for me was for a wrapper that's there whether you have the fallback content display or not
<dholbert> lea: doing that with a nested element... you have to wrap the slot with a separate element... I suppose that'd work
<dholbert> lea: there was a reason, but I need to remember it
<keithamus> q+
<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_
<Rossen6> ack lea
<dholbert> emilio: there are use cases for exposing slots as parts, thats's what the details element ended up doing
<dholbert> emilio: but the question is why would you do details::slotted::div (?) instead of details>div
<Rossen6> ack keithamus
<emilio> s/details::slotted::div/details::details-content::slotted(div)/
<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
<dholbert> keithamus: it kind of exposes an impl detail of the shadow dom that might be undesirable
<emilio> q+
<dholbert> keithamus: would you have to make it unmatchable in a closed shadow root?
<Rossen6> ack emilio
<dholbert> emilio: we resolved to add :has(:slotted) , so that detail would already be exposed via that pseudo-class
<dholbert> keithamus: good point, maybe we should ???
<lea> s/:has(:slotted)/:has-slotted/
<emilio> s/:has(:slotted)/:has-slotted/
<dholbert> dbaron: even though it's a closed shadow-root, it's exposed as a part. there's supposed to be something exposed there
<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?
<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
<dholbert> emilio: some are useful. you can do ::part ::placeholder to style a placeholder - that's an actual thing that was requested
<dholbert> emilio: I'm not sure we should go to great lengths to avoid matching ::has(::slotted)
<dholbert> er :has-slotted
<emilio> s/::has(::slotted)/:has-slotted after ::part()
<dholbert> lea: if we decide not to do it, can we revisit this in the future?
<dholbert> lea: or will we be hit by webcompat in that scenario?
<emilio> +1 to dbaron
<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
<fantasai> +1 to dbaron
<dholbert> dbaron: and I can't even really promise that we can do it now
<dholbert> Proposed resolution: don't allow ::slotted after ::part
<dholbert> RESOLVED: don't allow ::slotted after ::part
<lea> When do we reconvene?
<astearns> lea: 7 minutes ago officially, but I am guessing 5-10 minutes from now
<keithamus> We are reconvening
<emilio> scribe+

@mozilla-apprentice mozilla-apprentice mentioned this issue Sep 27, 2024
Closed
@chromium-helper chromium-helper mentioned this issue Sep 30, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
css-scoping-1 Current Work css-shadow-parts-1 Needs Edits
Projects
CSSWG Agenda TPAC 2024
Status: Friday afternoon
Milestone
No milestone
Development

No branches or pull requests
5 participants
@LeaVerou @dbaron @tabatkins @astearns @css-meeting-bot