- From: Kurt Catti-Schmidt <notifications@github.com>
- Date: Wed, 11 Feb 2026 14:13:15 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1000/3887509449@github.com>
KurtCattiSchmidt left a comment (w3ctag/design-reviews#1000) @jyasskin > I'd be more comfortable if it treats "./styles.css" as a specifier that can be overridden by an importmap. Yes, this is how it behaves, it is a specifier that goes through import map processing. @jakearchibald and @LeaVerou > Does anything else on the platform behave like this? The existing [`cite` attribute](https://html.spec.whatwg.org/#attr-blockquote-cite) accepts a URL but doesn't perform a fetch. There is also [`itemid`](https://html.spec.whatwg.org/#global-identifiers-for-items) and [`itemtype`](https://html.spec.whatwg.org/#attr-itemtype). These are somewhat obscure and metadata-ish attributes, but there is some precedent. A closer fit is probably Import Maps, where the URL's in the JSON text content aren't fetched as part of Import Map parsing. The values for `shadowrootadoptedstylesheets` need to be URL-like, as they must point to *something* that can be either declarative or a separate file, and the specifier syntax is the best way to handle that. If an external file is referenced via `shadowrootadoptedstylesheets`, the way to fetch and add to the module map is via the existing `<link rel="modulepreload" as="style" blocking="render" href="./foo.css">`, which will fetch, add to the module map, and potentially block rendering (among other things). Expecting `shadowrootadoptedstylesheets` to perform a fetch doesn't really work because: 1) There is not enough information to do a fetch from a string alone (should it block rendering? CORS? etc.). The `<link>` tag is capable of all of this. 2) The imperative `adoptedStyleSheets` API doesn't fetch, so fetching via an attribute would be inconsistent with that 3) The order of the adopted stylesheets array must be as specified for proper CSS application. If it were to perform a fetch, we would need to block rendering until *every* fetch completes so that the order can be maintained and CSS can be applied properly. Applying them one-by-one out of order while they load is an option, but they need to end up in the original order specified, which could produce multiple FOUC's as the fetches complete. 4) What happens if a fetch fails? `<link>` already has `onerror` to handle this. The `<template>` element from declarative shadow DOM disappears from the DOM when parsed, so there's no element to attach events to. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1000#issuecomment-3887509449 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1000/3887509449@github.com>
Received on Wednesday, 11 February 2026 22:13:20 UTC