Re: [csswg-drafts] [selectors] Pseudo-class to indicate when a slot has content (#6867)

I like that there is a resolution here, being able to select on this content is going to be a massive improvement for shadow root users at large. Many thanks for trudging through this! 👏🏼 👏🏼 👏🏼 

---

However, there's one last thing that I think is highly important to consider with this feature...

The fact that many developers have difficulty grasping the nuances of styling shadow DOM and leveraging `::slotted(...)` to begin with should point us away from using the language "slotted" in this feature. The resolution above for `:has-slotted` not to select against content that can be addressed with `::slotted(...)` today means it will be just as confusing as it is powerful when shipped as is. I can tell you as a person who has trained more people to work with shadow DOM than I can count over the last 10+ years that if we make the "slotted" in `::slotted(...)` mean something different than the "slotted" in `:has-slotted` it will make learning these APIs even more difficult.

### Example

Beyond the simple inability to address text nodes with `::slotted(...)`, there are other cases where "fallback content is not being displayed" but content isn't "slotted". If you have the following custom elements:
```html
<my-button>
  <template shadowrootmode="open">
    <slot name=icon>Fallback content</slot>
    <slot></slot>
  </template> 
</my-button>
```
And it is leveraged within a larger pattern as follows:
```html
<larger-pattern>
  <template shadowrootmode="open">
    <my-button>
      <slot name=icon slot=icon></slot>
      This is a button
    </my-button>
  </template>
</larger-pattern>
```
The `<my-button>` within the `<larger-pattern>` will not display the "Fallback content" even though it does not _technically_ have anything "slotted" within it as seen by not being able to address `::slotted(slot)` within the styles of the `<my-button>`. 

*Note: while "slotted text" is central to the OP here, knowing when an actual thing is slotted is a much wider pain that becomes harder to solve if we step on the language that should be used to do that work.*

### Alternatives

- Continue to rhyme with `:has(...)` and do something like `:has-assigned`, which opens the door for `:has-assigned-elements` and `:has-assigned-nodes`, etc., etc.
- Clarify the difference between this and other features by using something like `:fallback-displayed` so we can achieve the OPs goals with `slot:not(:fallback-displayed)` while staying more true to the newly resolved functionality of this feature.
- Attempt to correct some of the shortcoming in `:empty` by introducing `:text-node`/`:empty-text-node-only`-like selector that allows us to do things like `.el:is(:empty, :not(:empty-text-node-only))`, `slot:has-slotted(:text-node)` and `slot:has-slotted(:empty-text-node-only)` et al.
- Focus on `:has-slotted` rhyming functionally with `::slotted(...)` by default and return to understanding the presence of text node in the future. 

-- 
GitHub Notification of comment by Westbrook
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6867#issuecomment-2580502755 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 9 January 2025 15:02:38 UTC