Re: [csswg-drafts] `::details-content` vs `details::part(content)` (#9951)

>     1. While it is true we are not taking away names web developers can use, it is still utterly confusing.

I'm not sure I agree, it is confusing the first time because it's new, but long term it's IMO less confusing, specially for developers already familiar with parts.

>     2. It create an inconsistent API with `::placeholder`, `::marker`, `::file-selector-button`, `::thumb`/`::slider-thumb`, etc.

Sure, though same thing, that's a one-time issue. That's also fixable (e.g., you can expose `::file-selector-button` as an alias of `::part(selector-button)` and so on, conceptually).

>     3. `::part()` is very much tied to open/closed shadow trees. For built-in elements the way they work should remain up to implementations, even if we decide to define their subtree in terms of internal shadow trees (not open/closed) in the specification. Using `::part()` however deviates from that as that's specific syntax tied to open/closed shadow trees. I'm very much opposed to start exposing implementation details.

I'm not sure I get this argument. We already define `<details>` in terms of a shadow tree. Can a user agent implement using something else? Lot of effort, but sure. But you could also make `::part` work in that (hypothetical) set-up.

---

An aside / another topic worth looking into, is that there's another difference between `::part()` and pseudos that I think might be worth discussing, which is which element do they inherit from.

Pseudo-elements always inherit from its originating element, while `::part()` uses the usual flat tree rules. For `::details-content` in particular it might not be an issue, because those would end up being the same (the `<details>` element), but for newer form controls or things like `switch`, where you may want to define e.g. the thumb as a child of the track, it can cause confusing behavior:

```css
input { color: red }
input::slider-track { color: green }
input::slider-thumb { background-color: currentColor; } /* red! */
```

Alternatively, we might want to have a weird "part-like pseudo-element" that behaves like this... But that's a new CSS concept.

---

I think that if we're going to define new controls in terms of shadow trees, using `::part()` would be the right thing to use to expose the inner elements. It's more powerful, way less special.

The big drawback that I see with `::part()` is feature-detection / not being able to use `@supports selector(::details-content)` or so.

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


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

Received on Friday, 8 March 2024 09:43:51 UTC