On Wed, Jan 28, 2026 at 7:06 PM Kurt Catti-Schmidt (SCHMIDT) < [email protected]> wrote:
> Hi Yoav, > > Thanks for the input. Responses below and inline. > > > - Can you expand on how developers are supposed to use this? Would > they need to add particular attributes that would let the browser know that > the modules preloaded are CSS/JSON? Is there a way for developers to detect > browser support for this? What happens if there isn't? Is there a risk of > preloading modules that would then not be used? > > > Good point, there's no explainer and the summary was missing examples as > to how this is supposed to be used, so this has been addressed with the new > sentence "Style modules can be preloaded with <link rel="modulepreload" > as="style" href="..."> and JSON modules can be preloaded with <link > rel="modulepreload" as="json" href="...">." The "as" attribute is necessary > to opt into these new supported module types, and absence of it defaults to > a script modulepreload. > > For this feature, developers don't need to detect support, as preloads are > a hint for the renderer to preload for a later import, and they can't > guarantee that a preload has completed by the time it's used. If the import > was preloaded, it's a cache hit, and if not, it's a fetch - either way > there's still an import, so there's no need to detect support. For browsers > that don't support modulepreload, a <link rel="modulepreload"> tag does > nothing, and for browsers that only support script modulepreloads (and not > style or JSON), <link rel="modulepreload" as="style"> was considered > invalid and will also do nothing (see > wpt.live/preload/modulepreload-as.html). > That's great!! > Note that some browsers do log to the console when invalid values are used > for modulepreloads. > > Preloading modules that are not used later wastes bandwidth, but there's > no risk of site compat. Many browsers will also notify developers of this > situation in developer tools - Chrome logs "The resource <URL> was > preloaded using link preload but not used within a few seconds from the > window's load event. Please make sure it has an appropriate `as` value and > it is preloaded intentionally.". > > > - Links to the positions filed? > > > I updated the links inline in the original email, but they look similar to > the old links, so it probably looked like I didn't update anything. Here > they are separately: > https://github.com/mozilla/standards-positions/issues/1342 and Support > style and JSON as modulepreload destinations · Issue #603 · > WebKit/standards-positions > <https://github.com/WebKit/standards-positions/issues/603>. > > > -Kurt > > ------------------------------ > *From:* Yoav Weiss (@Shopify) <[email protected]> > *Sent:* Tuesday, January 27, 2026 11:57 PM > *To:* blink-dev <[email protected]> > *Cc:* Mike Taylor <[email protected]>; blink-dev < > [email protected]>; Kurt Catti-Schmidt (SCHMIDT) < > [email protected]> > *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: JSON and style > support for link rel=modulepreload > > > > On Tuesday, January 27, 2026 at 8:34:32 PM UTC+1 Mike Taylor wrote: > > Thanks - looks like we're just waiting for annevk (or another HTML editor) > to merge https://github.com/web-platform-tests/wpt/pull/56617 and > https://github.com/whatwg/html/pull/11981#issuecomment-3771477272? > > > On 1/23/26 12:35 p.m., Kurt Catti-Schmidt (SCHMIDT) wrote: > > Hi Mike, > > Thanks for taking a look. Standards Positions for WebKit and Mozilla have > been filed and added to chromestatus. I also added the Finch feature name > to chromestatus and updated the fields in the email below. > > -Kurt > > ------------------------------ > *From:* Mike Taylor <[email protected]> <[email protected]> > *Sent:* Thursday, January 22, 2026 6:58 PM > *To:* Kurt Catti-Schmidt (SCHMIDT) <[email protected]> > <[email protected]> > *Cc:* blink-dev <[email protected]> <[email protected]> > *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Ship: JSON and style > support for link rel=modulepreload > > > On 1/22/26 3:56 p.m., Chromestatus wrote: > > *Contact emails* > [email protected] > > *Explainer* > *No information provided* > > > Can you expand on how developers are supposed to use this? Would they need > to add particular attributes that would let the browser know that the > modules preloaded are CSS/JSON? > Is there a way for developers to detect browser support for this? What > happens if there isn't? Is there a risk of preloading modules that would > then not be used? > > Good point, there's no explainer and the summary was missing examples as > to how this is supposed to be used, so this has been addressed with the new > sentence "Style modules can be preloaded with <link rel="modulepreload" > as="style" href="..."> and JSON modules can be preloaded with <link > rel="modulepreload" as="json" href="...">." The "as" attribute is necessary > to opt into these module types. > > For this feature, developers don't need to detect support, as preloads are > a hint for the renderer to preload for a later import. If the import was > preloaded, it's a cache hit, and if not, it's a fetch - either way there's > still an import statement, so there's no need to detect support. For > browsers that don't support modulepreload, a <link rel="modulepreload" > as="style"> does nothing, and for browsers that only support script > modulepreloads, <link rel="modulepreload" as="style"> is considered invalid > and will also do nothing (see wpt.live/preload/modulepreload-as.html). > Note that some browsers do log to the console when invalid values are used > for modulepreloads, but this won't break any sites. > > Preloading modules that are not used later wastes bandwidth, but there's > no risk of site compat. Many browsers will also notify this in developer > tools - Chrome logs "The resource <URL> was preloaded using link preload > but not used within a few seconds from the window's load event. Please make > sure it has an appropriate `as` value and it is preloaded intentionally.". > > > > *Specification* > https://github.com/whatwg/html/pull/11981 > > *Summary* > Adds support for JSON and style module types as <link rel="modulepreload"> > destinations. <link rel="modulepreload"> is already supported in Chromium > (see https://chromestatus.com/feature/5762805915451392), but it currently > only supports preloading script-like module scripts. This feature addresses > a functionality gap, as JSON and CSS module scripts are supported in > Chromium elsewhere but are not supported as <link rel="modulepreload"> > destinations. Style modules can be preloaded with <link > rel="modulepreload" as="style" href="..."> and JSON modules can be > preloaded with <link rel="modulepreload" as="json" href="...">. > > > *Blink component* > Blink>DOM > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EDOM%22> > > *Web Feature ID* > modulepreload <https://webstatus.dev/features/modulepreload> > > *Motivation* > Style and JSON are fully supported as modules in Chromium (see > https://chromestatus.com/feature/5948572598009856 and > https://chromestatus.com/feature/5749863620804608), but <link > rel=modulepreload> only supports preloading script modules. This feature > addresses a gap in the platform. In addition, supporting "style" as a > modulepreload destination addresses a pain point identified when using > external files with Declarative CSS Modules (see > https://chromestatus.com/feature/4790543041298432). > > *Initial public proposal* > https://github.com/whatwg/html/issues/10233 > > *TAG review* > *No information provided* > > *TAG review status* > Not applicable > > *Risks* > > > *Interoperability and Compatibility* > *No information provided* > > *Gecko*: No signal (Support style and JSON as modulepreload destinations > · Issue #1342 · mozilla/standards-positions > <https://github.com/mozilla/standards-positions/issues/1342>) > > *WebKit*: No signal Support style and JSON as modulepreload destinations > · Issue #603 · WebKit/standards-positions > <https://github.com/WebKit/standards-positions/issues/603> > > Issues don't count as formal position requests - can we please file them? > See > https://www.chromium.org/blink/launching-features/wide-review/#signal-process > > > Links to the positions filed? > > I updated the links inline in the original email, so it probably looks > like I missed it. Here they are: > https://github.com/mozilla/standards-positions/issues/1342 and Support > style and JSON as modulepreload destinations · Issue #603 · > WebKit/standards-positions > <https://github.com/WebKit/standards-positions/issues/603>. > > > > *Web developers*: No signals > > *Other signals*: > > *Ergonomics* > This feature will increase ergonomics with CSS Module Scripts (see > https://chromestatus.com/feature/5948572598009856) and Declarative CSS > Module Scripts (see https://chromestatus.com/feature/4790543041298432). > No known ergonomics risks. > > *Activation* > No polyfill is necessary, as a module import will succeed regardless of > whether it's preloaded or not. In unsupported browsers, it will do nothing. > > *Security* > No security risks. > > *WebView application risks* > > *Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications?* > *No information provided* > > > *Debuggability* > Basic support via the Network tab in DevTools, which displays preloaded > resources from this feature. > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > Yes > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > https://github.com/web-platform-tests/wpt/pull/56617 > > *Flag name on about://flags* > *No information provided* > > *Finch feature name* > ModulePreloadStyleJson > > *Non-finch justification* > This is not a new feature, just an expansion of an existing feature, so > Finch is not necessary. > > Per > https://chromium.googlesource.com/chromium/src/+/HEAD/docs/flag_guarding_guidelines.md#When-is-a-flag-required, > we should land this change behind a feature flag, in case things go > unexpectedly wrong. Can you do that? > > Done via ModulePreloadStyleJson > > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/466888680 > > *Measurement* > There is already a UseCounter for <link type=modulepreload> (see > https://chromestatus.com/metrics/feature/timeline/popularity/2232). I > plan on adding an additional UseCounter for style module preloads. > > *Estimated milestones* > Shipping on desktop > 146 > Shipping on Android > 146 > Shipping on WebView > 146 > > > *Anticipated spec changes* > > *Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way).* > *No information provided* > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5202661416763392?gate=6500470023651328 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69728ee9.050a0220.19f748.008b.GAE%40google.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69728ee9.050a0220.19f748.008b.GAE%40google.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BCMLB5NQ8S0r%3DRU0U_JUJ23rRxfGbWwmHQcy_z3z3g5Q%40mail.gmail.com.
