Allow "style" and "json" in as attribute for modulepreload

[KurtCattiSchmidt]

Updates the definition of modulepreload to support as="style" and as="json" for preloading style and JSON module scripts respectively. Also removes as=json for rel=preload, as the only use for preloading JSON is for a module import, so it might as well directly add it to the module graph via modulepreload. There were some inconsistencies with the existing spec's supported as values for rel=preload, which this PR fixes with the introduction of a "preload destination" concept, which includes all supported types.

Fixes #10233

• At least two implementers are interested (and none opposed):
  • Chromium
  • WebKit
• Tests are written and can be reviewed and commented upon at:
  • Add tests for modulepreload links with JSON and CSS, remove json with non-module preload web-platform-tests/wpt#56617
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/466888680
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=2004751
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=303761
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A, as this feature is unrelated to accessibility.
• MDN issue is filed: PR here: Updates to modulepreload and preload to incorporate WHATWG changes for "style" and "json" mdn/content#42333
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/acknowledgements.html ( diff )
/indices.html ( diff )
/links.html ( diff )
/semantics.html ( diff )

[annevk]

Should we also disallow "json" for <link rel=preload>?

[KurtCattiSchmidt]

Should we also disallow "json" for <link rel=preload>?

You're right, "json" doesn't really make sense in preload if it's supported for modulepreload. I think this should be handled separately though, because WebKit recently added support for <link rel=preload as=json>, and we can have both for some window of time.

Filed #11995 to track and discuss separately.

[annevk]

I'd rather tackle them together as I have a feeling #11995 will not be addressed anytime soon otherwise. And it would be good to have that infrastructure in place as we add more types, such as text and bytes.

[KurtCattiSchmidt]

I assumed there would be some window of overlap between the new and deprecated version, which is why I filed a separate bug. But if we can do them in one shot that's great. This feature is a little different in that it's not directly observable, so it does seem safe to just deprecate.

I'll update this PR to remove <link type="preload" as="json"> today.

@rniwa - you recently added support for <link type="preload" as="json"> in WebKit so your input here is appreciated.

[KurtCattiSchmidt]

Latest push handles removing "json" for "preload". I also added the implementation bugs. I'll work on tests next.

[KurtCattiSchmidt]

Tests and MDN PR's have been are added, so the only missing part in compliance above is "two implementors are interested". @rniwa - can you give a WebKit position in https://bugs.webkit.org/show_bug.cgi?id=303761?

[bakkot]

Note that the set of module types might be expanding - there's active proposals for text and bytes imports from JS.

[KurtCattiSchmidt]

@annevk - you mentioned a missing conformance section for the as attribute, but I don't see an existing section for it, just https://html.spec.whatwg.org/#attr-link-as. Is this something I should add? Or is the table I edited in this PR under https://html.spec.whatwg.org/#attributes-3 sufficient?

[annevk]

@KurtCattiSchmidt those are the conformance requirements. You'll have to adjust the wording there to make it clear json is not a valid potential destination. Maybe something like:

Each potential destination except for "json" is a keyword for this attribute ...

Or maybe define preload destination as a concept which takes care of that.

[KurtCattiSchmidt]

Thanks @annevk - it was awkward updating "potential destination" to exclude "json" everywhere, so I added a preload destination concept. This reduced some duplication elsewhere too.

[smaug----]

Excluding a single thing this way is a bit icky special case, and special cases tend to cause issues later. Would there be some other way to express this (if we need to exclude json. Not sure why we need to, but perhaps it doesn't matter too much.).

[annevk]

We might have to exclude more module destination types going forward. One way to avoid this would be to refactor Fetch's destination concept to have subtypes or some such. But not sure we need to go there right away.

[KurtCattiSchmidt]

Added a "preload destination" concept in the latest push that instead lists all supported module types (in addition to the "module preload destination" concept added for module preloads).

[noamr]

Should we also disallow "json" for <link rel=preload>?

It's already disallowed. See https://html.spec.whatwg.org/multipage/links.html#translate-a-preload-destination
It's probably enough to add json and style to modulepreload specifically.

[KurtCattiSchmidt]

Should we also disallow "json" for <link rel=preload>?

It's already disallowed. See https://html.spec.whatwg.org/multipage/links.html#translate-a-preload-destination It's probably enough to add json and style to modulepreload specifically.

Not exactly, https://html.spec.whatwg.org/#consume-a-preloaded-resource lists JSON as a preload destination. I reverted to the prior commit in this PR, which removes that part and adds "style" and "json" to modulepreload. Does this version look correct @noamr?

[annevk]

This looks great @KurtCattiSchmidt, thanks for tidying it all up. @smaug---- @noamr any final thoughts?

I suggest we merge this Monday next week.

[noamr]

This looks great @KurtCattiSchmidt, thanks for tidying it all up. @smaug---- @noamr any final thoughts?

I suggest we merge this Monday next week.

Re-read the PR, looks good to me!

[KurtCattiSchmidt]

This looks great @KurtCattiSchmidt, thanks for tidying it all up. @smaug---- @noamr any final thoughts?
I suggest we merge this Monday next week.

Re-read the PR, looks good to me!

@noamr - would you mind hitting the +1 button again? You had previously approved, but it reset when I re-requested review.

[KurtCattiSchmidt]

This looks great @KurtCattiSchmidt, thanks for tidying it all up. @smaug---- @noamr any final thoughts?

I suggest we merge this Monday next week.

Thanks Anne! We have a holiday on Monday so I'll plan on landing on Tuesday unless any new issues arise.

[annevk]

The editors will take care of the merging (and are available on Monday). Unless you wanted to push it back one day? Though it wouldn't give the US an extra day so then we'd have to merge Wednesday.

[KurtCattiSchmidt]

If someone else is merging then Monday is fine with me, thanks for checking.

[annevk]

I wanted to merge this, but it appears that web-platform-tests/wpt#56617 is not yet in a good state. We want to merge WPT and this change together so I'll wait for that to get updated.

[KurtCattiSchmidt]

I wanted to merge this, but it appears that web-platform-tests/wpt#56617 is not yet in a good state. We want to merge WPT and this change together so I'll wait for that to get updated.

Just pushed some updates, hopefully the bots are happy now. Will check again tomorrow morning.

[KurtCattiSchmidt]

@annevk - bots are all clean on the WPT's

[KurtCattiSchmidt]

WPT's landed! @noamr @dandclark @smaug---- - can someone land this during @annevk's absence? He mentioned he'll be out until February 10th.