6 ms·
Slots require shadow DOM which means there can be performance and CSS issues on widgets designed for local use with shared CSS. But I agree they’re also an opti
by lstamour 8y ago
Slots require shadow DOM which means there can be performance and CSS issues on widgets designed for local use with shared CSS. But I agree they’re also an option. :)
- FiddlyPack 8y ago:part and :theme CSS puesdo-selectors will help address these issues
- no_wizard 8y agoyou can also use :host, which target the custom element specifically (and using :host on custom-element children does not, from what I recall off hand, get broken when nesting) and then target its children. Also, css variables can be global and still enter into the shadow-dom unobtrusively (This is without using the polyfills, though, I believe this is a limitation in the polyfills currently, which might be why that part of it has been confusing in the past.).
- gedy 8y agoThis. I feel like an old man yelling at a cloud, but while everyone seems to focus on how awesome shadow DOM and isolated CSS is, I need to deal with using a global theme and styles.
- ww520 8y agoI have the same problem with global styles when using Web Components. Using @import in the components to include the shared style files solve the problem.
- spankalee 8y agoPerformance issues? Native Shadow DOM, especially with Constructible Stylesheets, is a perf boost. Limiting style resolution to smaller scopes and less rules is good.
- dfabulich 8y agoPerf boost compared to what? It can't be a FCP perf boost relative to server-side rendered plain old CSS and HTML, because shadow DOM requires client-side JavaScript. Plain old CSS is able to parse and render before the JS required to launch web components has even finished.
- lowkeyokay 8y agoIt can be a performance boost because it only updates the part of the DOM tree that has changed. Not completely unlike React’s virtual DOM
- lstamour 8y agoTrue, I don’t have benchmarks, but there was a time period where shadow DOM was popularly disabled due to performance hits, but perhaps it was all the performance hit of polyfills and less efficient implementations in browsers. https://github.com/WICG/construct-stylesheets/blob/gh-pages/explainer.md https://github.com/WICG/construct-stylesheets/blob/gh-pages/... is interesting, though Sass still looks unlikely to be added to the browser so we’ll always need some amount of CSS compilation if you want CSS nesting the way you expect it in Sass. Here’s more documentation on constructible stylesheets: https://developers.google.com/web/updates/2019/02/constructable-stylesheets https://developers.google.com/web/updates/2019/02/constructa... I wasn’t aware of this because this stuff is being developed and released so dang quickly! (I do worry that APIs developed in relative haste might be replaced or iterated on in relative haste, especially if they aren’t adopted widely first...)
- dosy 8y ago:is() can make concise CSS of some of what nesting does in Sass https://developer.mozilla.org/en-US/docs/Web/CSS/:is https://developer.mozilla.org/en-US/docs/Web/CSS/:is there's a lot New coming into web all the time. I watch chrome status for drops. https://www.chromestatus.com/features https://www.chromestatus.com/features
- zaphar 8y ago
- ww520 8y agoShared CSS can be dealt with using @import.