[@sheet] Using stylesheets embedded in the element contents itself presents a potential performance risk

As I spelled out in https://github.com/w3c/csswg-drafts/issues/11547, there's a serious perf risk embedding style-loading elements directly into the DOM in commonly used elements. The problem is that of stylesheet caching, because every sheet has to be calculated anew for every <style> and <link rel="stylesheet">. TL;DR:

Alternatively, I could inject all the global styles with duplicate <link rel="stylesheet">s. This comes with serious performance concerns: imagine a hundred posts on a TweetDeck-style UI for a microblogging site, each with <format-time> to format the time, <user-link> to format the username, and <format-text> to format the text. If you have 5 stylesheet tags on the site (say, normalize.css, your site's styles, Bootstrap, and a couple Bootstrap plugins) and want to use them all in that custom element's shadow DOM, that's 500 <link rel="stylesheet"> elements in that one page. The browser can cache style parsing per-URL to avoid the memory blow-up, but the browser can't avoid having to compute the entire stylesheet for every page, leading to high style compute times.

This is why, in https://github.com/whatwg/html/issues/10933 + https://github.com/w3c/csswg-drafts/issues/11547 (my proposed alternate solution), I don't embed URLs directly, but instead link to elements that have the needed data to load. There needs to be some way to ensure that the shared styles are not cloned, even if it's not the specific way I proposed.

I do like the idea of blending something like your @sheet blocks with my attribute-based linking, though. I'm envisioning those @sheet blocks in a global namespace, and maybe shadowrootadopt="foo bar ..." to add them to declarative shadow DOMs.

Start by reading the linked WHATWG HTML issue 10933 and CSSWG issue 11547, then compare their proposed approaches for sharing styles across declarative shadow DOMs. The issue is complete only when a concrete mechanism is specified clearly enough to address stylesheet duplication and style-computation costs; no implementation files or tests are identified here.