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

>  Style encapsulation is good (who wants to use a leaky abstraction??) and the goal should be to augment it, rather than replace it.

I'm not saying that we should replace style encapsulation. We've all agreed that the styles declared inside a shadow root should stay encapsulated. So the layering feature being discussed isn't about replacing style encapsulation. Its about priority of external styles and encapsulated styles together.

> Typically, there are resets, the base styles for a component (e.g. a base class like .navbar in Bootstrap), then variants, and then themes. You’ll even notice that components which are composed by others are ordered first.

I agree these things exist, but we should examine what happens in a world with open-stylable available. Today, component authors put their resets inside shadow root styles because they must. In a world where the page reset will simply apply to component styles automatically via open-stylable, component authors wont necessarily need a shadow-root scoped reset since the external style level reset will apply. The same might also be said for base styles.

In a world where open-styable components exist, why wouldn't page/component authors just move the majority of reset and base styles to the external context and NOT provide/repeat those styles in the shadow-root scoped context for every instance of some component? In a world where open-stylable exists, why wouldn't page authors have components JUST be theme and variant styles for that component, and leave the reset/base layers to the external context since those layers will undoubtedly be grouped together in one layer/stylesheet a lot of the time? I've never seen a reset sheet/file JUST for buttons. Resets are are global stylesheets like 99.9% of the time. Base styles tend to be similar i would suppose, though possibly more often broken up into individual stylesheets or partials.

> By providing them these layers as hooks, they can more deterministically “slot” their styles where they need to go for the proper effect.

My worry here is that component creation is already complicated. Adding on a css layers public API with a potentially complex/keyword-driven implementation in addition to the attributes, properties, parts, export parts, slots, cross-root aria that all already have quirks that make web components difficult to some.

Secondly, I still want to ask the question of "where are the userland approaches that show a 'layers as component hooks' api in framework-land"? If we're supposing that 'layers as hooks' is desired by component/page authors and users, then there should be examples out there of doing this 'layers as hooks' approach today, shouldn't there? If there aren't any/many examples of 'layers as component style hooks', doesn't that mean that its not a problem/blocker that app developers actually have?



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

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