@LorenzKahl @jensimmons @mozilla I don't spend much time looking into Reader Mode, so I've not noticed this. When you're delivering content via DSD, are you later upgrading those #customElements or simply using #declarativeShadowDOM? The influence of JS in that area would surprise me less, even if it were still not the optimal behavior in that case...
@jensimmons @westbrook @mozilla is it a known issue that Safari & Firefox Reader Mode ignore content rendered by Web Components in the Shadow DOM - even SSR‘ed content using DSD (iOS & Mac)
New Kitten release
• Now leaves <style> tags within <template> tags alone when collating and normalising the CSS on a page so as not to interfere with scoped styles in declarative shadow DOM.
(Kitten’s Streaming HTML workflow¹ – which uses htmx and WebSockets under the hood – combined with built-in support for slots, etc., in Kitten components² means the use of declarative shadow DOM is mostly useful if you want scoped styles. Ideally, of course, use classes to scope styles to your components and be specific in your CSS selectors in general so as not to pollute elements in your components. Although that’s a bit like saying you should floss everyday. Yeah, we all know we should…) :)
Update: All that said, I’d highly recommend you don’t use Shadow DOM in your Kitten apps. For one thing, htmx’s WebSocket extension doesn’t seem to play well with it. And for another, you really don’t need it and definitely not just to get scoped CSS.
Enjoy!
¹ https://kitten.small-web.org/tutorials/streaming-html/
² https://kitten.small-web.org/tutorials/components-and-fragments/
Using #DeclarativeShadowDOM to render placeholder content that gets replaced later as the #HTML #streams in with no #JavaScript!
https://lamplightdev.com/blog/2024/01/10/streaming-html-out-of-order-without-javascript/
This is an interesting technique, but it has limitations in that you can't close the #customElement until you've loaded the content.
@ryantownsend In https://github.com/WICG/webcomponents/issues/939 we're theorizing the declarative sharing of repeat <style> tags. Structured initially for #declarativeShadowDOM, but feels like something that could apply to prelude-less @scope, too. I wonder if that would make it practical/productive to blend test no. 1 and no. 3 in your demo https://css-scope-test.netlify.app/ and whether an approach that like that could even further reduce the paint times these tests are clocking...
So many great encapsulation strategies, so little time!
<style>
p {
color: blue;
font-size: 2rem;
}
</style>
<my-el>
<style>
@Scope {
:scope {
&, * {
all: revert-layer;
color: red;
}
}
}
</style>
<p>This text is red & small!</p>
</my-el>
<my-el>
<template shadowrootmode="open">
<style>
* {
color: red;
}
</style>
<p>This text is red & small!</p>
</template>
</my-el>
So I got nerd-sniped by @passle and their very cool out of order #HTML streaming demo with #DeclarativeShadowDom and no client-side #JavaScript.
https://techhub.social/@passle@mastodon.social/111709021508609514
I spent yesterday playing around with this idea and came away with a `streamOutOfOrder` tagged template literal which is able to apply this optimization to any interpolations. It even composes itself correctly and can load the whole page optimally out of order, no matter how large or complex it is.
Take a look and "View Source" to see how it works!
#shadowDOM partners with the likes of `:not(:defined)` to make progressive enhancement a more natural part of component development than ever.
#declarativeShadowDOM builds on top of that, and once Firefox ships things powerful API the distance between "page load" and "page needs JS" can be even further apart.
It's powerful to lean into the existing web APIs to learn new and exciting ways to support our clients while continuing to push the boundaries of those APIs at the spec level.
