Skip to content
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

Closed
jameschurchman opened this issue Jan 23, 2015 · 8 comments
Closed

Web Components #408

jameschurchman opened this issue Jan 23, 2015 · 8 comments

Comments

@jameschurchman
Copy link

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

@jameschurchman
Copy link
Author

any thoughts on this?

@philipwalton
Copy link

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.

You can import it into every single web component that i use but this :
a ) Seems a bit repetitive

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.

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 ?

While it's true that a new DOM <style> node will be made for every single component, it's actually not a performance penalty (at least not in Chrome) because browsers can recognize that these are all the same style and optimize for it. In fact, because the styles only apply to a DOM subtree, it's actually a performance gain because the browser doesn't have to compare those rules against the entire document.

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 ?

Absolutely not. /deep/ has horrible performance.

@philipwalton
Copy link

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.

@jameschurchman
Copy link
Author

Hi Philip thanks very much for your reply!
Yes i decided to just add one extra import to every single web component .. this seemed the easiest!

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?
Also my question was with regards to when it gets used with a polyfill which for most users will be their experience behind the scenes, especially on mobile. In this case would using /deep/ be faster, or alternatively using it import for every component be very very slow?

@jameschurchman
Copy link
Author

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

@philipwalton
Copy link

Also my question was with regards to when it gets used with a polyfill which for most users will be their experience behind the scenes, especially on mobile.

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.

@necolas
Copy link
Owner

necolas commented Mar 30, 2015

Closing for now. I think Philip has answered this better than I can.

@necolas necolas closed this as completed Mar 30, 2015
@itsMattShull
Copy link

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants