Re: [w3c/webcomponents] Provide a lightweight mechanism to add styles to a custom element (#468)

+1 from me on this idea; I'd wondered about an author-controlled "UA styles" a few years ago, early in the project, and this API surface feels good, better than whatever else I'd come up with.

I presume that the selectors are meant to be interpreted "like" a shadow stylesheet, right?  So they only apply to the element and its contents, and don't leak out to the global level?  In that case this is pretty easy - just need to specify that the styles are interpreted in the [user-agent origin](https://drafts.csswg.org/css-cascade/#cascade-origin-ua) and all of its selectors are [scope-contained](https://drafts.csswg.org/selectors/#scope-contained) by the host element.

I think using `:host` is fine - it has a very similar meaning here to what it does in shadow DOM, and that makes things easier to understand.  Do we plan to "hide" the host element, like you get in real shadow DOM?  (I think we should, to keep the similarities as high as possible.)  If so, then we just need to additionally say that, for the purposes of these selectors, the root element is featureless and matches `:host`/`:host()`/`:host-context()`. (This is more-specific-overriding-general, contradicting the general rule that `:host`/etc represents nothing outside a shadow tree.)

Question: do we want to *necessarily* tie this to the registerElement() call? Or do we want to allow embedding this into your global CSS too, so that even if your JS is slow or broken, your page at least doesn't totally break?  We'd put it under a `@custom-element foo-bar {...}` rule or something similar.  We'd just need to define an ordering for the JS sheet vs the CSS ones; I suspect the JS sheet should come afterwards, so they'll win in case of conflict.

---
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/468#issuecomment-203118573