-
Notifications
You must be signed in to change notification settings - Fork 10.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Web Components #408
Comments
any thoughts on this? |
In general this space is still evolving. Shadow DOM is, at the moment, fully capable of sharing styles, but sometimes it's a bit awkward/unintuitive to make this work.
Yeah, so you'd probably want to abstract this to a build step. Tools like Polymer let you use link tags in shadow DOM templates, so that makes this a bit easier.
While it's true that a new DOM
Absolutely not. |
To answer your over-arching question: at the moment I think the best practice is to import all of normalize.css into the styles of your shadow root. If you're using Polymer, you can make a base, "normalize-css" element that all your other elements extend from to avoid the repetition. This will effectively put normalize's rules in an older shadow root for every single custom element. |
Hi Philip thanks very much for your reply! You said that /deep/ has poor performance but is it any different to just having a huge single dom with global style as we have at the moment with out web components? |
the reason why i ask is the css for each component is small, so relatively far more css will be part of normalize, and normalize uses lots of global selectors, but with the ployfill will these now be global selectors prefixed with a parent tag selector , duplicated many many times for each component? if thats the case the performance could be crazy bad |
To be honest I haven't tried, but you could easily do so and see what happens. If it does you could always hack this together yourself. Since browser that don't support Shadow DOM just need a global normalize.css, and browser that do support Shadow DOM don't need the polyfill, you could conditionally add normalize.css to an older shadow root based on feature detection. Anyway, this seems like more of a Polymer question at this point than a normalize.css question. |
Closing for now. I think Philip has answered this better than I can. |
@pmgower and I were discussing this today and I came across this thread. He suggested breaking normalize up into scss partials that can be imported in so I did that here: https://github.com/aristotle-labs/normalize.scss/tree/master/partials Hope this helps in case anyone else finds this thread in the future! |
So whats the best practice for using normalize.css with web components ??
You can import it into every single web component that i use but this :
a ) Seems a bit repetitive
b ) Does this give performance issues when used with a polyfill ? Will it generate all the css hundreds of times over for each web component ?
Is a better option to produce a web components version of normalize.css that prefixes everything with /deep/ so that a single import will fix everything ?
On the flip side importing normalize.css into a web component has the benefit of not altering any embedded html from external sources
The text was updated successfully, but these errors were encountered: