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

I like the general motivation, but not sold on this implementation. How Is this different from @ apply (assuming it will be eventually implemented and will work cross shadow boundary)?

I say this as a non-designer backend developer, who occasionally has to put output on the screen, but its not large enough portion of project to hire dedicated designer. I grab some nice ThemeForest bootstrap template, strip away parts I don't need, and apply MVC to it, such that, say, `input group` HTML blob goes into CustomElement's shadow root, and make JS api through attribute change handlers to interact with it. The problem here, is those CSS themes (emphasis on *themes*) by their nature cannot be cleanly broken down into independent components. Eg, all have a certain border and background style, be it a text field, or a panel. There are very large style inheritances that in current and proposed (i think) way, need to be duplicated per component (preprocessors at least makes it automated).   Occasionally we do call a designer guy, but same principle applies: development of looks is very separate from development of custom elements, and does not follow same code hierarchy and inheritance rules.

The map approach, unless I do not understand it, still will require me to extract element-specific chunks of global theme into `defineStyles` map *together* with large chunks duplicated, if these style keys are encapsulated.  Developers who do not know any better will just stuff entire CSS libraries into each component. Eg, for a text field I have to include `input-group`, `form` and all of the base, which includes **all type of fields and basic page layouts**, not just text input that I want, and even in this this new proposal occurs **per style definition**. So in those cases I use light DOM, but it defeats the purpose of having a smaller DOM tree to look through in inspector.

>  I can see how someone might argue this would break encapsulation,

For themes outsourced/created by a designer and then passed on to a coder this is actually a good thing. That's why proposed https://tabatkins.github.io/specs/css-shadow-parts/ in chrome 63's release notes is a good compromise to removal of deep selectors. I can extend designer's theme by adding my deliberately exposed `parts` of shadow dom as additional style selectors of main theme. Or assuming `apply` rule can talk to parent document from within shadow root, I tell my element that it should `apply` some style I bought/outsourced.

-- 
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-367199489