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. :)

Performance issues? Native Shadow DOM, especially with Constructible Stylesheets, is a perf boost. Limiting style resolution to smaller scopes and less rules is good.

True, 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/... 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/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...)

  :is()

can make concise CSS of some of what nesting does in Sass

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

Very early ShadowDom had worse performance, but the major browsers have been hard at work improving it for a while now. I haven't benchmarked in several years but I wouldn't be surprised to find that it is now a boost in many cases.

You might want to check out https://cssdb.org/#nesting-rules native nested CSS rules have hit stage 1!

I checked the spec earlier and it’s impossible to make it backwards compatible with Sass without some slight edits, at least according to their GH issue on it. It’s worth watching though I suspect <style type=“text/scss”> or something like it will be added before we see broad adoption! :)

Possibly. I think the extra `&`s are something that could wash out with one-time tooling, and that the desire for `@nest .parent &` would bump the conversion rate, but it's always fun to watch the comings and going of standards.

Perf 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.

It 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

This. 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.

I 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.

:part and :theme CSS puesdo-selectors will help address these issues

you 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.).

Shared CSS can be dealt with using @import.