LGTM2 On Monday, February 2, 2026 at 9:06:29 PM UTC+1 Alex Russell wrote:
> An enthusiastic LGTM1; thanks for dotting i's and crossing t's. > > Best, > > Alex > > On Monday, February 2, 2026 at 10:12:43 AM UTC-8 [email protected] > wrote: > >> Both of those PR's are now merged. >> >> ------------------------------ >> *From:* Mike Taylor <[email protected]> >> *Sent:* Tuesday, January 27, 2026 11:34 AM >> >> *To:* Kurt Catti-Schmidt (SCHMIDT) <[email protected]> >> *Cc:* blink-dev <[email protected]> >> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: JSON and style >> support for link rel=modulepreload >> >> >> 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* >> >> *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. >> >> *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 >> >> >> *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? >> >> >> *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/90b2ec0c-94a0-461f-986b-c22e24047a5an%40chromium.org.
