Support link modulepreload for import assertions

[uasan]

Hello.
The current implementation in Chrome does not support the <link rel=modulepreload> for import assertions
https://bugs.chromium.org/p/chromium/issues/detail?id=1274871

The specification says that you can specify the as attribute

Let destination be the current state of the as attribute (a destination), or "script" if it is in no state.
https://html.spec.whatwg.org/multipage/links.html#link-type-modulepreload

But as not support and has not valid as value for type json module.

Perhaps it makes sense to add support for the type attribute?

for ESM module
<link rel="modulepreload" href="app.mjs">

for assert type css
<link rel="modulepreload" href="style.css" type="text/css">

for assert type json
<link rel="modulepreload" href="data.json" type="application/json">

Thanks.

[annevk]

cc @whatwg/modules

[dandclark]

I agree that this is needed, thanks for raising the issue.

Instead of using MIME type for the values, I think we could just use the same shorter strings as import assertions:

<link rel="modulepreload" href="app.mjs">
<link rel="modulepreload" href="style.css" type="css">
<link rel="modulepreload" href="data.json" type="json">

For the attribute name, type is nice in that it matches the name for import assertions, but I wonder if it should be more specific to prevent confusion with <link> use cases other than modulepreload. Maybe a name like:

<link rel="modulepreload" href="style.css" moduletype="css">`

or even

<link rel="modulepreload" href="style.css" modulepreloadtype="css">

An alternative idea is to add new rel values for each type:

<link rel="modulepreload" href="app.mjs">
<link rel="cssmodulepreload" href="style.css">
<link rel="jsonmodulepreload" href="data.json">

[bmeck]

I think having some way to do this is good, but it seems precarious given that arbitrary key/values are allowed for assertions to only cater to a single one as a special case.

[domenic]

I think @dandclark is on the right track. The main thing to consider is how well such ideas fit with possible future extensions.

• As @bmeck says, what happens if we add future import assertions to the web? This seems quite unlikely, and so maybe not worth complicating the spec for. But we should consciously decide one way or another.
• Relatedly, Adding scriptElement.exports for configuration use cases #7367 brings up a way to make inline JSON and CSS modules useful. Although there are more complications there, as I outline in Inline JSON and CSS module scripts #7415 , maybe the syntax we use for modulepreload could help with that design, or at least match with it?

For example, as a strawperson, you could imagine something like assert="... JSON string ..." and then the syntax would be something like

<link rel="modulepreload" href="style.css" assert='{ type: "css" }'>

<script type="module" assert='{ type: "css" }'>
.class { prop: value; }
</script>

This unfortunately has the usual quote-related problems of putting JSON in attributes, so it's mostly just a strawperson. But it's worth thinking about.

[uasan]

I, as a full stack developer, love when knowledge can be reused.
Therefore, I like the option most of all to use the same MIME types for clients and backend.

@domenic, Tell me the type = module is it so historically, because ESM appeared later?

<script type="module" >

In a perfect world, was it supposed to be like this type = application/javascript?

<script type="application/javascript" >

[domenic]

No, type=module is intentional. Application/JavaScript is not correct.