W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2019

Re: [csswg-drafts] [css-shadow-parts] What's the purpose of multiple idents in ::part()? (#4412)

From: Peter Linss via GitHub <sysbot+gh@w3.org>
Date: Wed, 16 Oct 2019 17:40:55 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-542812945-1571247654-sysbot+gh@w3.org>
> Can you explain a little more why you think the tagname is valuable?

My concern is more architectural than functional. (Tho there are functional differences in the cascade order.)

To be clear (to ensure we're on the same page and for anyone catching up with the thread), the current model allows custom elements to surface internal stylable components (shadow parts) as a single new type of pseudo-element, a `::part()` that has 1 to n labels. What I'd rather see is the ability for custom elements to surface internal components as custom pseudo-elements themselves, where the custom element declares the pseudo-element type. I agree that a pseudo-element type by itself doesn't expose sufficient information and think that custom pseudo-elements should also be able to expose class and custom state (`:state()`).

Exposing part names in a `::part()` type pseudo-element is something new. The part names behave similarly to classes for selector purposes, but they're not classes. They don't expose the part names in APIs like classes. They also don't fit into the cascade like classes.

By exposing a single pseudo-element type, and an optional set of classes, the shadow parts behave like regular pseudo-elements, and don't add anything new to the platform (except the fact that they exist). They fit into the selector model in a predictable and standard way. They'd also fit into any future Houdini APIs that expose pseudo-elements as their own type of pseudo-element without needing any additional API surface to expose the 'part name' concept.

One of the fundamental purposes of custom elements was to give authors the ability to do things that the platform does natively. I'd like to see shadow parts be a true custom pseudo-element, that look, act, and feel like regular pseudo-elements, rather than a new kind of pseudo-element that has different behavior and API surface. 

We also expect custom-element authors to 'pave the cow paths' and create new elements that can be added to the platform later as they become popular and show user need. By making shadow parts a different kind of pseudo-element, with different behavior, we make it harder to add them to the platform with equivalent semantics and behavior. I also expect common custom pseudo-element types to evolve where semantic meaning can be derived from their type, where their classes (or part names) would remain purely something with meaning only to the page author.

Frankly, I'd also like to see custom elements expose shadow parts as *standard* pseudo elements as well. What can't a custom input element expose a `::placeholder`?

> If it's purely a (custom to the page) semantic distinction, note that I've had several occasions in my webdev life when I've wanted to give an element multiple IDs, so I could address it differently in different contexts. The fact that DOM happens to impose a "0 or 1" semantic on IDs is a relic of the model; there's nothing semantically wrong with having multiple of them. As a result, I've moved something from being an ID to being a class just so I can give it multiple "names".

Note that I'm not precluding the shadow part from actually having multiple types, e.g. a part could be a `::part(placeholder)` *and* a `::part(label)`, similar to the way grid lines can have multiple names. The user of the component doesn't need to know that the two roles are played by the same part in one element, where they may be played by different parts in another (or another state of the same element).



-- 
GitHub Notification of comment by plinss
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4412#issuecomment-542812945 using your GitHub account
Received on Wednesday, 16 October 2019 17:40:56 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:54 UTC