Shadowdom and external styles?

[hirako2000]

Thanks for the brilliant library. I was wondering how to make yoffee elements use global stylesheet(s) rather than scoping the styles to shadow-root.

I like scoped styles, but this isn't very practical when a global sheet is used across every element anyway.

Any input would be welcome, the question really is how one would go about applying an arbitrary css library.

[lefetmeofefet]

Thanks a lot! I'm really happy that you find the library useful :) Later today I'll send you an example of my preferred way of doing what you described.

On Sun, Sep 26, 2021, 14:25 Hirako @.***> wrote:

Thanks for the brilliant library. I was wondering how to make yoffee elements use the global stylesheet rather than scoping the styles to shadow-root.

I like scoped styles, but this isn't very practical when a global sheet is used across every element anyway.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lefetmeofefet/yoffee/issues/2, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEOEHNEC4RU3KNBB2PH2PDUD4GJ7ANCNFSM5EYXUJHQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[hirako2000]

fyi the non web-component, html constructs, actually satisfies what I need. It's very neat to have the yoffee state mechanism working without having to create a web component. I for some reason thought it had to be a component for the state to reactively propagate.

Still curious about an approach to apply global styles to components, just no rush :)

[lefetmeofefet]

It's good to hear that you appreciate creating html templates within templates without creating new web-components. It's what I liked about lit-element as well :)

About styles - I like using scoped styles as much as I can, and when I really need something shared I use css variables. But still, sometimes you would want a global stylesheet, which I don't like because it breaks encapsulation, and potentially confuses the life out of whoever reads the code next and tries to understand where the style came from. So one simple thing you can do is to just import the css stylesheet inside each component that needs it.

A note about the data propagation - when you create a template inside a template, the data propagation is straightforward - prop changes, relevant html node changes. But when you want to propagate data into another element, for example changing an attribute, the changed element's onPropUpdate function will be called and it will be up to the element to implement it and react. Another way of interacting with the element is calling it's functions plain and simple.

Hope yoffee helps you, feel free to ask any question you'd like! :)

[hirako2000]

Thank you for your thoughtful response.

First, yes I do favour creating and reusing fragments rather than web components. And while I understand the purpose of shadow dom, and the benefit of scoped styles, I don't think they aren't beneficial in all scenarios.

(Global) Cascading style sheets have advantages I simply can't identify with scoped styles. Here are a few:

1/ Each common style is only transfered once over the wire. That's at last as many bytes saved. In some cases it adds up and does matter. AFAIK even with shared in-line styles, they would be loaded more than once.

2/ A shared style is already there in the global sheet. No need to import a shared style and apply it to each scope. In some cases, it does add up to have to type more than we should have to. In both cases one needs to know it exists. I would argue it's also easier to parse a number of pure style files, than parsing potentially furtive files that may contain more than just styles.

3/ One of the powerful features of web components and scoped styles, is the ability to created shared UI libraries. Composable elements that multiple projects can share rather than having to recreate them in each repo or module. I'm all for the DRY dogma. And modularity is great. Except that styling changes doesn't need markup changes. They better be decoupled to let each pipeline not worry (too much) about the other. Either way, each contributor to web components used by a project needs to have a grasp of the styling standards applied throughout, to maintain consistency.

4/ Last but not the least: Ask a senior, principal, fellow or godlike visual engineer, who of course knows CSS, to step in and make those last minute adjustments for the next release in a code base of scoped or even in-line styles and see how that goes. Do ask a senior web developer who of course understand CSS enough, to make those tweaks in stylesheets and see the difference. Either way nothing gets done if the code base doesn't reflect best practices for anyone to safely make a small change, but certain coder abilities don't appear to be commonly obtained by visual gurus.

5/ Overrides. I don't see how to override scoped styles without touching the source code. We can call this a hack, but reality is that more often than we think, we are posed to make styling changes to something that perfectly works as is, and simply don't have the luxury to dive too much into some code we've never seen before.

I may be opinionated, perhaps some of my claims aren't entirely correct or plain wrong, but so many have been suffering one issue or another that it's been holding the adoption of scoped styles, and in turn, the adoption of web components as the shadow'd dom appears to be an obligation rather than just an option.

On your note about importing the stylesheet in each web component's scope:

a/ it doesn't appear to work when I tried with yoffee, but I didn't try to figure what I may have done wrong, or used that one wrong browser.

but more importantly: b/ I don't trust it won't have some performance impact. It wasn't allowed by the spec originally, and browsers implementations all aren't being clear at all about what it implies.

I do have another question for you, but it isn't related, I will raise a separate issue.

Thanks!