4 ms·

what about slots?

• lstamour 7y 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 7y ago
    :part and :theme CSS puesdo-selectors will help address these issues
    • no_wizard 7y ago
      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.).
  • gedy 7y ago
    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.
    • ww520 7y ago
      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.
  • spankalee 7y ago
    Performance issues? Native Shadow DOM, especially with Constructible Stylesheets, is a perf boost. Limiting style resolution to smaller scopes and less rules is good.
    • dfabulich 7y ago
      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.
      • lowkeyokay 7y ago
        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
    • lstamour 7y ago
      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/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 7y 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 7y ago
  • ww520 7y ago
    Shared CSS can be dealt with using @import.