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

@nt1m 
> I think the only reason ::part(name) has been designed as it is to avoid author names impeding with future built-ins.

No, that was *one* reason. The other reason was to allow the class-like semantics, where an element can be exposed and/or targeted via multiple part names. (As the co-author of the spec, I can speak definitively on this.)

@rniwa 
> The whole point of ::part syntax was to namespace shadow DOM / custom elements so that they won't conflict with builtin pseudo elements.

It was to namespace, yes, but the conclusion you're subsequently drawing from that (that the UA should never be allowed to use ::part()) is incorrect. The ::part() namespace of a component is owned by the *owner of the component's shadow DOM*. Arbitrary authors cannot interfere with a given component's names (unlike many other namespaces we explicitly carved out for authors, like custom properties). So, since the `details` shadow is owned by the UA, the ::part() namespace for it is owned by the UA as well. It is 100% safe for the UA to expose parts.

> I'm immensely annoyed that this topic is getting re-litigated again.

This isn't particularly appropriate to express in this venue.

@annevk 
> ::part() is a web developer namespace. This would be akin to standardizing data-* attributes. While it is true we are not taking away names web developers can use, it is still utterly confusing.

I sympathize with "confusing", but this is still a meaningfully distinct situation from `data-*` attributes, or most other author namespaces we've carved out.

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

This is the big argument against ::part(), I think.

> ::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 what "open/closed" has relevance here, but yes, it does expose the fact that the element has a shadow tree (or at least masquerades as having one). This is already supported in the spec in any case - authors aren't allowed to install a shadow tree of their own on `details`.

@emilio 
>> [allow exporting a pseudo-element as a part]
> I think that'd be super weird, to target something sometimes as part and sometimes as pseudo-element. 

Well right now the choice is "target it as a pseudo-element" (if you have access to the originating element) or "you can't target it at all, sucks to be you" ^_^. I think allowing the second situation to become "target as a part" is an improvement; it allows people to, say, wrap a `details` in their `image-spoiler` component and still expose the contents bit. Or have a form component that wraps an `<input type=file>` and exposes its `::file-chooser-button` or whatever.

> Also we probably don't want to do this for all pseudo elements, it's unclear what exposing a first-line should do, for example?

Right, it would need to be tree-abiding pseudos only. Non-tree-abiding are virtually always an exception.

> I think that's not great alternative, and if we go for a pseudo element we should just tell people to export the whole details element for such use case (which might not be what they want, necessarily, but would allow you to do ::part(details)::details-content the same way you can do ::part(input)::placeholder nowadays.

Yeah, it's possible, but awkward. ^_^ It forces the author to expose the fact that something *is* implemented as a `details`, rather than hand-rolled. This isn't *strictly necessary* to avoid, but we do try to avoid exposing such implementation details when we can. 

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9951#issuecomment-1986120259 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 17:33:13 UTC