- From: Kurt Catti-Schmidt <notifications@github.com>
- Date: Fri, 13 Feb 2026 10:36:31 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1195@github.com>
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