Re: [w3ctag/design-reviews] Question: should `shadowrootadoptedstylesheets` perform a fetch? (Issue #1195)

justinfagnani left a comment (w3ctag/design-reviews#1195)

@KurtCattiSchmidt I am personally not a fan of using `<link>` for this exactly because it adds an element for every use of a shared stylesheet, which is definitely in the hundreds to thousands in many cases.

Design systems can have multiple shared stylesheets (color, typography, surfaces, etc) per element times hundreds of element instances. Removing the element after parsing is odd and a conceit we had to make for declarative shadow DOM that I wouldn't want to repeat unless absolutely necessary. Even if we did that, you still have to parse and create those many elements.

As for control of blocking and errors, my main focus is still deduplicating the styles we emit today with declarative shadow DOM. Those today are inlined, not fetched, so when solving today's use case, fetching isn't part of it.

For the new feature of fetching, I prefer to emulate how the page would have rendered from the same components client-side rendered with JS modules. In those cases the components wouldn't have rendered until their styles loaded (assuming styles are loading via JS or CSS modules), so blocking is necessary to fully emulate that behavior. Non-blocking use cases today would require something opt-in like a `fetch()`, dynamic `import()`, or  adding `<link>` tags to a template, which are still available for non-blocking use cases.

IOW, if you want to _not_ block, you already can with `<link>`, and that will still be true. So `shadowrootadoptedstylesheets` fetching _should_ block.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1195#issuecomment-4362055519
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1195/4362055519@github.com>