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

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

I want to preface this by emphasizing that the core use case for this feature is in server-side rendering of web components. @justinfagnani has had to re-explain this multiple times, e.g. at https://github.com/mozilla/standards-positions/issues/1081#issuecomment-3560266264, and I don't want to make him do it again here. The question about how a specifier-based mechanism handles "URLs that aren't already in the module map" is about ensuring that the new mechanism is consistent with the rest of the platform and avoids sharp edges, but it's unlikely that the core use case will run into this part of the feature.

I was chatting with @bkardell, and we both have the sense that "yes, this should fetch", but that raises @KurtCattiSchmidt's questions about _how_ it should fetch. So:

The proposal currently uses `<template shadowrootadoptedstylesheets="specifier1 specifier2 ...">`, where if one of the specifiers is an unfetched URL, there's no way for developers to control "render-blocking"[^1] or error handling. If the proposal used the https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md#using-a-link-tag-to-adopt-stylesheets alternative from the explainer:

```html
<template shadowrootmode="...">
  <link rel="adoptedstylesheet" specifier="specifier1">
  <link rel="adoptedstylesheet" specifier="specifier2">
  ...
</template>
```

Then developers could use normal `<link>` features to control render-blocking[^1] and error handling.

[^1]: In this situation, "render-blocking" might mean that the shadow DOM waits to be attached until all dependencies are ready, as opposed to the [traditional kind](https://html.spec.whatwg.org/multipage/dom.html#render-blocking-mechanism) that can't add render-blocking elements after the body has started.

@domenic was worried about this possibliity in https://github.com/whatwg/html/issues/10673#issuecomment-3222362601:

> the explainer [suggests](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md#using-a-link-tag-to-adopt-stylesheets) maybe using a <link rel="adoptedstylesheet" specifier="foo"> syntax. Then you could use sheet="" or media="", and we'd have room for future extensibility, e.g. maybe respecting blocking="".
>
> ... I don't like reusing <link>, because right now <link> is always about a hyperlink to the URL specified in the href="" attribute. (There's the slightly strange case of rel="expect", but even for that we tried hard to give it hyperlink-ish semantics, and it uses #foo URLs in the href="" attribute.) This would be the first case where we're basically using <link> to mean "a generic reference to something", and departing from href="".

I feel like the `specifier` attribute keeps `<link>`'s quality as a hyperlink to a URL, even though it indirects that URL through any import map. It means the URL isn't always in the `href` attribute, but what concrete problems is that going to cause?

The `rel="adopedstylesheet"` or `rel="adopt stylesheet"` is somewhat orthogonal to the `specifier` attribute. I couldn't justify the need to put these into the `adoptedStylesheets` list if sheets can be shared in another way, but I also see that it's useful to let libraries keep the same object structure they're currently using.

@jakearchibald, @keithamus, and others, do you have any sense of whether it would help to define `<link specifier>` for importing/adopting this kind of sheet?

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

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