W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2020

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

From: Peter Linss via GitHub <sysbot+gh@w3.org>
Date: Sat, 09 May 2020 01:25:37 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-626083059-1588987536-sysbot+gh@w3.org>
> Again, nesting parts isn't possible right now and we probably don't want to make it possible. It exposes internal structure that we probably want to hide.

While it doesn't have to be a V1 feature, there's no reason to not allow custom element authors to expose whatever structure they want to, so long as it's a choice, not a side-effect of implementation. As I showed in my example, that structure can be useful. I'm not trying to expand this issue into nested parts, but it's worth seeing how these selectors play in a world where nested parts exist.

> ::part() isn't a third thing for the authors of the component to decide on (or for the users of the component to have to remember which values correspond to it). It's a syntax hack over the pseudo-element name.

But part names are a completely new thing. I expect the majority of custom pseudo-element will only have a single name, so no additional cognitive load on authors. If they're designing something with multiple names, it may be a good idea to make them think about why and what those names mean, they are creating an implementation contract after all.

Also, custom element authors already understand the concept of minting element names, and using tags vs attributes (e.g. should it be &lt;foo> and &lt;bar> or &lt;thing type="foo"> vs &lt;thing type="bar">, same concept). I expect classes won't be a surprise to them either. Tag names and classes also aren't anything new for the consumers of those elements. Whereas part names that are sort of tag-like and sort-of class-like are a new concept are are more likely to cause confusion than clarity, especially if they have a new syntax to boot. I know the idea was surprising to me, and I've been doing this for a while...

All existing pseudo-elements are clearly explainable as having a single tag-like name. Class-like part names don't directly map onto anything else in the platform.

And I'm glad we agree that `:part()` is a hack :-P

> As far as I can tell, my proposal is perfectly compatible with this idea? What makes you think it isn't?

I suppose it is, I admit I'm having trouble keeping all the proposals straight. In my head, your proposal is still conflating part names with pseudo-element type and a class-like thing, so while doable, it feels hacky to me. In mine the pseudo-element type is explicit and only used for that. In my experience, when we mix concepts we tend to get bitten somewhere down the line.

GitHub Notification of comment by plinss
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4900#issuecomment-626083059 using your GitHub account
Received on Saturday, 9 May 2020 01:25:39 UTC

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