Re: [csswg-drafts] [css-shadow-parts] Unifying ::part() and ::--foo (#4900)

> Hopefully the :part() syntax can eventually be deprecated.
> [...]
>  I'd much rather see us fix selectors, e.g. your example could be ::--day:--weekend:--us-holiday (using custom state)

I disagree.

First, a more abstract objection: I don't think the tagname/classname distinction we currently have in the DOM is a *useful* distinction. It's something we inherited from DOM, but there's no meaningful difference between the two semantically; we even invented two "pretend I don't have a tagname" elements (`div` and `span`) to allow authors to supply their own semantic fully thru classes. The only thing tagnames meaningfully do is trigger browser-default behavior (`a` acts like a link, etc), but as far as CSS is concerned that's more or less a non-issue, and even then HTML is littered with exceptions (like all the various inputs clustered under a single `input` name despite varying behavior and semantics).

So I don't think we should be trying to introduce the same distinction for custom elements.  Elements have a set of idents with class-like semantics; there's no need for a tagname-like semantic, and forcing authors to *decide* which of their several possible idents qualify as "most tagname-like" is a decision we shouldn't force authors to make. We want to offer a tagname-like *syntax* for convenience, nothing more.

Second, a more concrete objection: having a custom element expose its part semantics as pseudo-classes clashes with the existing custom pseudo-class proposal.

As I discussed in #7, I've come to believe that custom elements are indeed the most appropriate place in the DOM to expose custom pseudo-classes; in particular, I think there is no need to add them to arbitrary elements in the light dom.  Custom Elements have their own, component-controlled semantics that need to be deployed as a separate namespace from the author-level semantic (classnames), so a pseudo-class with a distinct syntax space works out fine.

Exposed parts hit the same conflict: the part itself might be a custom element, which exposes its own custom pseudo-classes. The outer component already has a place to indicate class-like semantics on its elements, in the form of the part name; merging the two means there can be clashes between two not-necessarily-cooperating elements, same as a custom element exposing its states by manipulating its host's `class` attribute.

(In this, I am assuming that the part's custom pseudo-classes will be available for matching, same as most UA-defined pseudo-classes are. I don't think this is an encapsulation break.)

GitHub Notification of comment by tabatkins
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 24 March 2020 21:27:36 UTC