[css-shadow-parts-1] Naming of ::theme

[jakearchibald]

https://tabatkins.github.io/specs/css-shadow-parts/

As a spec reader & developer, I struggled to figure out the difference between ::part and ::theme. From https://twitter.com/jaffathecake/status/893430709632806912, it turns out ::theme pierces additional shadow boundaries, whereas ::part pierces only one.

Unless I'm alone, it might be better to reflect this difference in the naming. Eg ::part-deep().

[daKmoR]

I would prefer to split - e.g. provide part and theme as separate attributes as described here
#1972

[tabatkins]

And I've just done the split. I need to add some better wording to the spec about the difference between the two, tho.

[dbaron]

I had a similar reaction in w3ctag/design-reviews#230 (comment) ; I tend to think that ::part and ::theme are too closely related to have unrelated names.

But now I need to dig back in to understand what this "split" is. According to the spec they're still both selecting on the part attribute, which wasn't what I'd have imagined you meant by a split.

[daKmoR]

I think/home it will change to something like this

The ::part() pseudo-element allow you to select elements that have been exposed 
via a part attribute. The syntax is:

// ...

The ::theme() pseudo-element allow you to select elements that have been exposed 
via a theme attribute. The syntax is:
```

[lozandier]

@jakearchibald I personally find ::part & ::theme better than say ::part, ::part-deep. ::theme is more intuitive to me its application spans across all aspects of a component to be visually rendered. It's clearer to me the ultimate intent of the creative that decided to use ::theme: To select theme-able parts.

Something like ::part-deep communicates it extends beyond the current context, but it doesn't seem to communicate as much as ::theme

[domenic]

I have a related issue with the theme naming.

Consider someone making a control that wants to act like a built-in control, and expose its parts as pseudo-elements, like e.g. the nonstandard ::-webkit-progress-bar / ::-webkit-progress-value.

If you add

::-webkit-progress-bar { background: red; }

this will change all <progress> elements, including those inside of shadow roots. Right?

But if you did

my-progress::part(bar) { background: red; }

this would not change <my-progress> elements inside shadow roots. Right? Instead you have to do

my-progress::theme(bar) { background: red; }

It seems strange to me that we'd use the name ::theme(), or even ::part-deep(), for something that matches the normal expected platform behavior for built-in elements. It's not really related to theming, is it? It's just about actually styling the part, instead of getting stopped unexpectedly at boundaries.

I apologize if some of my logic is incorrect here (e.g., maybe ::-webkit-progress-bar styling also stops at shadow boundaries?). Let me know if so.

/cc @tkent-google @fergald

[tabatkins]

You say "stopped unexpectedly at boundaries", I say "correctly encapsulated behavior". ^_^

(e.g., maybe ::-webkit-progress-bar styling also stops at shadow boundaries?)

It does indeed, because selector matching does. ::-webkit-progress-bar exists on a progress element; the selector ::-webkit-progress-bar is implicitly equal to *::-webkit-progress-bar, which first targets the progress element (and a bunch others) and then goes down into its pseudo-children and targets the -webkit-progress-bar one.

A progress hidden in a shadow tree won't be targeted by the *, and thus you won't style its ::-webkit-progress-bar either.

The only exception to this is that the UA stylesheet exists simultaneously in all tree scopes, so it can target ::-webkit-progress-bar and apply default styling to it regardless of how deep in shadows it is.

[domenic]

Ah, great, OK, I have many fewer concerns then!