- From: Westbrook Johnson via GitHub <sysbot+gh@w3.org>
- Date: Thu, 31 Oct 2024 00:59:05 +0000
- To: public-css-archive@w3.org
I really like having _anything_ available in this area (is there any way that I can further explain the **high level** of important the web component developing community places on this API?). I am super excited about the implementation currently available in Chrome/Firefox (so many things we could never do have already been opened up to us with this API). However, not being able to select against the flattened tree will be a hard blocker on this API; maybe not today, maybe not tomorrow, but it will come up (much like questions around white space being "slotted") that would be better to be answered today, if only directionally. Personally, I can certainly be appeased with the selector matching `.assignedNodes({flatten: true})` _only_. For my experience, the ability to build complex, deeply slotted applications is and will continue to be greatly constrained by not supporting this. This also aligns it more directly with the behavior of `::slotted()`. However, `::slotted()` does present a questionable result in this example: ```html <div><template shadowrootmode="open"> <div> <template shadowrootmode="open"> <style> ::slotted(input) { color: red; } </style> <slot></slot> </template> <slot><input value="not styled" /></slot> </div> </template></div> ``` _Practically, we do need to support the spread._ ### Questions: **Does that mean multiple selectors?** `:has-slotted` and `:has-slotted-flatten` could be a path, though it's interesting to need to go between the two. **Does `flatten` belong in the functional version?** Always? Or as an option? `:has-slotted(.selector !flatten)` _could_ be a path, but how this would apply to slotted text content is unclear. Also, does this mean each selector in the method get this option? `:has-slotted(.selector !flatten, .other-selector)`, see `.other-selector` not feature flatten. Or would this need to be general to a single `:has-slotted()` usage? **Functionally, will component authors be doomed/required to "know" the slotted content depth?** ```html <div> <template shadowrootmode="open"> <div> <template shadowrootmode="open"> <div> <template shadowrootmode="open"> <style> p { color: red; } slot:has-slotted(slot:has-slotted(slot:has-slotted(p))) + p { color: green; } </style> <slot></slot> <p>Styled content</p> </template> <slot></slot> </div> </template> </div> </template> <p>Slotted content.</p> </div> ``` **Does a combinator approach mean that `/slotted/` and `/slotted-flatten/` could be made possible together, leveraged with better x-browser support for [`:host:has(...)`](https://wpt.fyi/results/css/css-scoping?label=master&label=experimental&aligned&q=host%20has%20internal), and clarify both this and other situations herein?** Can the combinator select on text? **Could any of these practically address selecting when content is delivered via the hole in `::slotted()` outlined above?** --- Many thanks to all who are investing time into making this a high-quality and powerful additions to the web platform! 🙇🏼♂️ -- GitHub Notification of comment by Westbrook Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6867#issuecomment-2448786192 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 31 October 2024 00:59:06 UTC