[CSS] A Protocol to cover the gaps while we wait for declarative CSS module support

[Westbrook]

@sorvell just mentioned this as a possible path to more immediate support for future specs like https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md from the community level.

[justinfagnani]

Anything here is going to require script, so developers would have to be ok with that. It's likely to be a small inlineable script though, so it'll be small and not risk additional FOUC.

Here's how I could see this working - and I'm not sure if it needs to be a protocol, vs a library and SSR system that uses it. Ie, it may be interoperable without elements opting in:

First some requirements/constraints:

• We need some kind of global identifier for stylesheets
• We need to be aware of shadow roots being created declaratively so that we can either scan them for styles, or apply styles to them. We can't patch .attachShadow() for this.
• We need to specify which stylesheets apply to a shadow root, and we can't use attributes on the <template> for this, because they won't be available.
• We want to attach styles to adoptedStyleSheets in the order the component actually has them in.

I think given the second constraint, the only solution is to use custom elements to detect when a shadow root is created. We can have an element that adopts styles to its root:

<my-element>
  <template shadowrootmode="open>
    <adopt-styles style-ids="0 1 2"></adopt-styles>
  </template>
</my-element>

Then we need an element to register a style:

  <style type="adoptable">
    ...
  </style>
  <adoptable-style style-id="0"></adoptable-style>

<adoptable-style> can appear anywhere in the document and it will register it's previous sibling <style> element and create a shared new CSSStyleSheet() object for that id. <adopt-styles> will simply look up the sheet for that id and push it onto adoptedStyleSheets.

I think the implementation could be just a few dozen lines of code. Something like:

class AdoptableStyleElement extends HTMLElement {
  static styleSheets = new Map();

  attributeChangedCallback(name, oldValue, newValue) {
    if (name !== 'style-id') {
      return;
    }
    const styleId = newValue.trim();
    const styleTag = this. previousElementSibling;
    if (!(styleTag instanceof HTMLStyleElement)) {
      return;
    }
    const styleSheet = new CSSStyleSheet();
    styleSheet.replaceSync(styleTag.textContent);
    AdoptableStyleElement.styleSheets.set(styleId, styleSheet);
    styleTag.remove();
    this.remove();
  }
}

class AdoptStylesElement extends HTMLElement {
  attributeChangedCallback(name, oldValue, newValue) {
    if (name !== 'style-ids') {
      return;
    }
    const root = this.getRootNode();
    if (!(root instanceof Document || root instanceof ShadowRoot)) {
      return;
    }
    const styleIds = newValue.trim().split(/\s+/);
    root.adoptedStyleSheets = styleIds
      .map((id) => AdoptableStyleElement.styleSheets.get(id))
      .filter((s) => s !== undefined);
    this.remove();
  }
}

[justinfagnani]

I was thinking about this more today, and it occurred to me that there might not be any use of a protocol here.

Protocols exist to enable interoperable implementations, but I don't see a clear situation where multiple implementations of this idea need to interoperate.

This technique requires some global-ish storage on both the client and the server (global on client, probably request-local via AsyncLocalStorage), and if there were multiple libraries emitting the script-implemented declarative stylesheets, then they would need to share the same stylesheet/id cache, but... until and unless we actually get multiple interacting SSR server libraries (ie, #7) I don't see that we would have that situation.

Right now SSR is done with one SSR server library, which would be using a particular implementation of this technique, and client-side that implementation will use its own cache.