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

@philipwalton (re: nesting) Yes, that's precisely what I was getting at when I was talking about `@apply`/nesting. ^_^  There's no specificity issues to iron out - It Just Works™.

@rniwa 
> Like we agreed during the last F2F, custom properties, @apply, and custom pseudo elements aren't conflicting ideas. They address slightly different use cases and both can be supported.

No, they don't address slightly different use-cases.  They address the *exact same* use-cases.

> In particular, in an isolated web component case where neither component nor its container document trusts each other, we can't expose all mixins defined in the container document into the shadow tree.

Sure we can.  And when you do want to block, that's what `all: initial` is for.  (Alternately, an equivalent of `all` for just custom properties has been proposed; it would be called `--`, as in `--: initial`.) You can then let particular custom properties thru with `--foo: inherit`.

> Also, there is an added benefit of developer familiarity with custom pseudo elements. While the technical problems faced by nested rules and @apply might be similar (or even simpler as you claim) to those faced by custom pseudo elements, relying solely on three brand new CSS syntax seems like a lot of cognitive load.

I already addressed this in my earlier reply to Rachel.

@othermaciej 
> (1) It's critical for component authors to be able to whitelist the set of style properties that can be applied to an exposed named part.

Why?  CSS doesn't do this today.  ::before/after take all properties.  ::first-line and friends don't, but that's because *they're not actually elements*, they're bizarre collections of fragments (to use CSS terms), and that limits what you can reasonably do with them.  That's not relevant to this topic, tho; we're only planning to expose actual elements here.

If you want to whitelist properties, that's best done with simple CSS variables - expose variables for each property you want to allow.  If you want to expose arbitrary styling but blacklist some properties for sanity, that's trivially done with @apply - just list the blacklist properties with their desired values after the @apply rule.  With custom pseudos, this is yet another new thing you'll have to define and introduce, presumably in JS.

> (2) I'm somewhat partial to :part syntax because then we never have to worry about namespace collisions with future CSS built-in pseudos.

Yes, `::part()` is definitely a preferable syntax for pseudo-elements here.

> (4) I don't think @apply plus the increasing series of other features that need to come along with it is a replacement. The syntax is pretty inscrutable. I immediately understand what Philip's named part examples are doing, but I don't understand what his @apply + nesting proposal does.

It's not "increasing", it's complete.  Variables/@apply/nesting are a complete styling feature.

The syntax is relatively new, but a lack of immediately familiarity doesn't automatically imply "inscrutable".  It's a declaration block stuffed into a custom property.  Nesting is familiar to users of every single CSS preprocessor in existence, and is consistently one of the most popular and highly used features.  The learning curve here is *miniscule* based on practical evidence.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/300#issuecomment-144551648