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

KurtCattiSchmidt created an issue (w3ctag/design-reviews#1195)

Relevant background:
Explainer:  https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md
TAG Review: https://github.com/w3ctag/design-reviews/issues/1000
Mozilla Standards Position Discussion: https://github.com/mozilla/standards-positions/issues/1081

As currently spec'd, `shadowrootadoptedstylesheets` on the `<template>` tag does not perform a fetch. We have received feedback that this is inconsistent and unintuitive for developers. We would like the TAG to consider this proposal and provide guidance on whether this should remain as-is, or be changed to perform a fetch in some manner. If it does perform a fetch, there are several open questions that need to be resolved.
 
`shadowrootadoptedstylesheets` accepts a space-separated list of specifiers. Currently, for each specifier, the module map is queried, and if a style module is present with that specifier, it is added to the `adoptedStyleSheets` array for the declarative shadow DOM that it is associated with.
 
There are several reasons why it is currently spec'd to not perform a fetch:
 
1. The imperative `adoptedStyleSheets` API does not perform a fetch, and we wanted the attribute to be consistent with the API as much as possible.
 
2. If it did perform a fetch, there would be no mechanism to catch errors via `onerror` (or success via `onload`), as the `<template>` tag is discarded after parsing. Also, `<template>` lacks attributes like CORS, blocking, and more that are necessary for a robust fetching mechanism.
 
3. The primary use case we've seen for `shadowrootadoptedstylesheets` is for declarative modules, which don't need a fetch. Alternatively, we could scope `shadowrootadoptedstylesheets` to only declarative modules, but that also seems inconsistent.
 
4. `adoptedStyleSheets` is an array, and the order matters for CSS rule application. Each fetch response would trigger an FOUC, and style computation must be rerun for each load completion. Any mutations to `adoptedStyleSheets` while the fetch is loading would trigger more style changes, but this would match the existing behavior of `adoptedStyleSheets`.
 
 
There are many ways to address this scenario, each with various tradeoffs. A few options:

1. Leave as-is, and do not perform a fetch. 
 
2. If not already in the module map, perform a fetch, but with no CORS, error handling or load events, and with an FOUC for each fetched module completion. This can be mitigated with `<link rel=modulepreload>` ahead of time (and could be warned via the console).
 
3. Only allow `shadowrootadoptedstylesheets` to accept declarative modules. This would avoid this issue, but is limiting and inconsistent. This could also be a temporary limitation.
 
4. Create a new type of `<link>` tag that populates `adoptedStyleSheets`. This would handle CORS and load/error events, but still has ordering/FOUC issues due to `adoptedStyleSheets` ordering/mutation and adds DOM mutations to the mix. It will also be very similar to the existing `<link rel="modulepreload">`, which could be confusing.

TAG guidance on this scenario is greatly appreciated. I would also like to thank @jakearchibald and @LeaVerou for bringing up this concern.

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1195


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

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

Received on Friday, 13 February 2026 18:36:34 UTC