Relying only on content type might be too late for certain optimizations

[phistuck]

What about one of the following?

import {baz} from html "foo.html";
import {baz} from html, "foo.html";
import {baz} from "foo.html" html;
import {baz} from "foo.html", html;
import {baz} from "foo.html", type "html";
import {baz} from [html] "foo.html"
import {baz} from [type = "html"] "foo.html"
import {baz} from [type: "html"] "foo.html"
import {baz} from {type: "html"} "foo.html"
import {baz} from {html: "foo.html"}

My https://discourse.wicg.io/t/specifying-nonce-or-integrity-when-importing-modules/1861 has some prior art for the syntax and some acknowledgement and suggestions by Dominic.

I am not developing a browser, but I imagine that knowing this in advance might be useful to trigger more optimizations.
Furthermore (or perhaps more importantly?), it would be more readable and self explanatory (.html is not mandatory in the URL).

[dandclark]

Off the top of my head I can't come up with any optimizations that knowing the desired MIME-type in advance would unlock. Even if the import statement specifies statically whether it expects HTML or script, we'll still need a MIME-type check after we've received the response from the server because we need to bail out if the file has the wrong type, or is sent without one specified. It's possible there are ideas here I'm missing though.

On the other hand the point about readability is well taken. Things could quickly get weird in an environment with mixed HTML and JS imports where many URLs are lacking extensions for whatever reason. I like the first one: import {baz} from html "./foo.html";, where one could alternatively specify script or just not specify and we'd default to script for backwards compat.

@domenic, did anything come of the discussion alluded to here? If there are extensions to the import syntax being discussed then perhaps we could fit into those if we decide to go this route.

[domenic]

Yeah. TC39 came down against any syntactic additions, advising that instead we either use the string specifier space (e.g. import { baz } from "html!./foo.html";) or use out-of-band metadata (such as Content-Type or a manifest file).

I think using Content-Type as the discriminator is the right choice, and we don't need to add "mandatory comments" of the sort the OP suggests.

[dandclark]

Thanks Domenic! Given that result from TC39, I'm going to mark this issue as closed and stick with using Content-Type. Readability issues can be mitigated by documentation/commenting where imported files lack extensions.

As an aside -- something I've been considering is that in many cases the importer might not even care whether an import is an HTML or a Script module. Consider this sort of use case:

import { templateElement } from "./some_import";
document.querySelector("#destinationElement").appendChild(templateElement.content.cloneNode(true));

In this case the importing code doesn't necessarily even care whether some_file was an HTML or a Script Module, just that it provided the correct type of exported content.