Re: [w3c/webcomponents] Support Custom Pseudo-elements (#300)

> I may not understand @apply very well. But it seems like @apply puts control in the hands of component authors for where stuff gets applied, and the expected API contract is that the client of the component provides some custom properties with the intended styles. But @theme applies style to all parts with a given name everywhere. And the component client has to decide whether to use @part or @theme. So the component's API contract is not just a specific name of the styling hook, but also the requirement to know whether they should use ::part or ::theme with it.

Not really.  Like I said above, `::theme()` is actually the almost-direct translation of `@apply`'s functionality back into the selector space (where this functionality belongs).  Every bad implication you can imagine `::theme()` having, `@apply` has, because inheritance lets you set the custom property arbitrarily far up in the flat tree, and it'll work it's way down to the component unless explicitly blocked (by the custom property getting set by an element somewhere between the component and the first element to set it).

`::part()`, on the other hand, is the better-designed API that you actually want.  It, plus part-forwarding, gives you access to precisely the parts that your component chooses to give to you, and it works consistently between open and closed shadows.

If we all collectively decided that we only wanted `::part()`, that's okay with me.  It's the good part of the proposal anyway.  I included `::theme()` because it avoids throwing away any power; this power is precisely what some Polymer people talked about as useful in their early feedback to me. And if we don't allow `::theme()`, we don't actually shut anything down, we just make similar usage vastly less convenient (the "big bag of custom properties" approach I talk about in the spec).

Ultimately, if you can pass a single value arbitrarily far down the flat tree without the intervening elements having to do anything (besides just fail to stop you), it seems weird to not allow sets of values; disallowing it doesn't actually add any security whatsoever, just makes it less convenient for component authors and users.

>  The fact that ::theme theoretically is similar in power in some sense to @apply is not a good reason to have it. 

Just to reiterate, it's not similar "in some sense" - it's *exactly* as powerful in a direct-translation sense - `@apply` and `::theme()` are mirrors of each other, just living in different parts of the CSS syntax space.  And `@apply` is only very slightly more powerful `var()`, just way more convenient for the use-case of allowing arbitrary styling on an element (only "more power" is that it allows setting arbitrary custom properties, which can't have their names predicted ahead of time).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/300#issuecomment-279528864