Re: [WICG/webcomponents] "open-stylable" Shadow Roots (#909)

Just as a sanity check, I feel the need to interject here just to double check that the particular order of layers inside a shadow root is actual a real need/desire that folks have today? If this implementation is more forward-looking instead of solving problems that exist today, thats totally cool, but I can't help but think that I've never seen the kind of layer ordering being proposed here done in any app (not that my anecdotal experience is super broad) composed of framework components that ought to be web components but cant be yet.

I will again posit that I believe that today's framework components are a model for the open-stylable feature. Part of the reason for the initial issue was to help make web components with shadow roots participate in apps more like frameworks do. I'm not saying that we shouldn't strive for a better world than we have today, but I've never seen in any app, any attempt at deciding which layers or styles from the page styles should apply to `MyReactComponent.tsx` or `MyVueComponent.js`.

Framework components today have 'encapsulated component-declared styles" via css modules, hashed data- attributes and classnames. Web components have enapsulated component-declared styles via shadow roots.

When framework components are included in an app, 99% percent of the time in my experience, they are thrown into a page along with all the other elements. All of the page styles that are "external" to `MyReactComponent.tsx` will apply to it. Layers included. I don't think it is very common for react/vue applications today to have some mechanism in css modules that says "I want only the `reset` layer to apply to `MyReactComponent.tsx`, and I want styles declared in `MyReactComponent.tsx` to be layered after the external `reset` layer". 

But folks are suggesting that this sort of complex feature is necessary for shadow root components. I'm not sure I agree.

Imo right now today, most if not all the layers that get defined, are defined externally to framework components. I've literally never seen the `@layer` keyword inside the styles of `MyReactComponent.tsx`. The external styles priority and specificity set a 'winning" selector for an element. The styles declared in `MyReactComponent.tsx` are also thrown into the mix because their hashed data- attribute increases specificity but rarely if ever, priority. 

But it seems to me that we're saying that the mere fact that there is a shadow root involved in web components somehow makes them different than `MyReactComponent.tsx` in terms of selecting which styles/layers get "into a shadow root" and the 'cross root" relationship of styles. I haven't heard anyone say that they do this sort of thing today with their react components. I haven't seen an application where "only the `reset` layer from my global styles applies to `MyReactButton.tsx` component".

Just a gut check here, but I have always thought that if we just get parity with framework components styling-wise that is a huge step. In order to implement the layer priority and sharing feature for shadow roots, shouldn't we first prove that its a need that folks have today with framework components?


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

Message ID: <WICG/webcomponents/issues/909/1996310419@github.com>