[task] milestone 0: <script type="module">

[caridy]

notes:

• deterministic compilation and execution of multiple <script type="module"> tags
• defer=true by default?
• initialization: a module that initializes/configure the loader should block any other import. how?
• charset resolution

[Constellation]

While implementing the prototype, I have encountered the issue, How "charset" / "crossorigin" attributes are handled?

For example, there are tags that finally load the same module.

<script type="module" charset="euc-jp" src="A.js"></script>
<script type="module" charset="utf-8" src="B.js"></script>

A.js

import "C.js"

B.js

import "C.js"

In the above case, which charset will be applied to C.js?
Will C.js with euc-jp be reused in B.js?

One idea I think is that, inserting the originator(tag)'s attributes to the module key.
As a result, in the above case, we load C.js module twice with the different attributes.

[caridy]

jajaja, I don't know, but I'm glad that you're raising this issue. Let me circle this back to other folks and see what we can do.

[caridy]

In theory (based on the conversation we had today), a and b will be raising (due to the network activity). a, and b will be also compiled (looking for deps), whichever raises to the completion of the fetch process will issue a fetch for c. This seems to be a real problem, I'm adding charset to the notes.

[domenic]

We should not allow charset, and always interpret as utf8, like workers do.

[Constellation]

How about crossorigin? I think it is ok enabling this by default.

edit:
Ah, but, we need to choose anonymous or use-credentials.

[caridy]

+1 on that jajaja. If we can settle on that, I can add the corresponding wording into the spec. @domenic, link to that piece in the workers' spec? or any discussion related to this topic in the context of the worker?

[Constellation]

And I'm also +1 on utf-8. The module will be rewritten from the old code because it includes non compat syntax and semantics. It's good time to require utf-8.

[caridy]

just to clarify my position: my +1 was on the utf8 comment from @domenic

[Constellation]

defer=true by default?

Is it necessary to wait page load completion? How about async with order restriction?

[caridy]

right, I should have clarified about the whole question including async/defer. I will add more notes about this tomorrow when I get home. GH mobile is very restrictive.

[Constellation]

@caridy:
Awesome!

[domenic]

We should get @annevk to help with deciding on crossorigin. Maybe we can actually enforce CORS this time.

For async-like vs. defer-like vs. something else, it is tricky. We need something; as @ajklein pointed out to me, using the default blocking behavior that <script> without attributes has is not good, because we can't block on all the imports (it'd be basically sync XHR). async with order seems reasonable, but it doesn't have any precedent, which is kind of annoying...

For a reference on workers, see worker processing model, step 6.

Although, I am wondering why we are allowing src at all, instead of asking people to do <script type="module">import "./A.js";</script>? I assume src uses normal URL resolution (with base URL etc.) and not module loader resolution?

[domenic]

One problem with async-with-order is that your DOM will be in a non-deterministic state. defer-like behavior, at least for the default, seems better? But I guess maybe "as soon as possible" could be argued to be better, since it's potentially faster...

[annevk]

I think CORS is a must since otherwise we have new SOP holes. "anonymous" seems like the best default.

Perhaps it can be defer by default and you can specify async to get ASAP without ordering?

[okuryu]

type attribute value must be a valid MIME type in the HTML Standard. Is this an exception or should HTML Standard cares it?

[domenic]

Yes, we would fix HTML. In fact presumably most of <script type="module"> would be defined in HTML once its definition has stabilized.

[okuryu]

Is improving the existing type attribute better than adding a new attribute like <script module>?

[annevk]

@okuryu by using type the contents will not be executed as non-module JavaScript in browsers that do not support the feature.

[okuryu]

@annevk Aha, good point! Thanks for your clarification.

[Constellation]

@domenic

Although, I am wondering why we are allowing src at all, instead of asking people to do <script type="module">import "./A.js";</script>? I assume src uses normal URL resolution (with base URL etc.) and not module loader resolution?

Nice catch! If we allow src attribute, we need to consider about <script type="module" src="std/math">. But personally passing the src attribute to the Loader.resolve is one solution I think. Or adding new attribute import="std/math" may solve the problem

[annevk]

If src does not match the semantics src normally has we should not use src. I would be fine with adding a new import attribute instead and make src a no-op when type=module.

[caridy]

The other aspect of this is backward compatibility. We have discussed in the past that maybe we can have a way to detect support for modules at the server side (using accept header), which opens the possibility of using <script type="module" src="path/to/file.js"> and get the server to send you either a module or script, depending on the accept header. Alternative, if we don't have src, we can simply walk all scripts with type=module, and execute them somehow in older browsers (which is totally fine) as wel.

note: I'm just trying to record all the ideas we have discussed in the past.

[domenic]

I think the minimal solution consists of one of two possibilities:

1. <script type="module" src>, with usual resolution semantics, and no "inline" modules. Normal usage presumably does <script src="url-of-bootstrapper.js">, where the file at url-of-bootstrapper.js sets up the loader and starts doing import statements.
2. <script type="module">, with no src or import, only an inline body. Normal usage is to set up the loader and start doing import statements inside your inline body.

Anything on top of these proposals, up to a full-fledged src attribute and/or import attribute and/or inline body combo, seems strictly more than minimal. I'd suggest pursuing a minimal strategy for now. (2) seems best.

[caridy]

Agree that (2) is way more simple, and I will be happy to pursue it.

As far as I can tell, using:

<script type="module">
import "foo";
</script>

will be completely ignored today, which means detection and polyfills can be implemented.

[guybedford]

I do think there is value in providing both (1) and (2) here, as they cater for different use cases.

Inline script is useful, but is disabled by CSP. Loading a single main entry point is a very common use case, so having its own property makes sense both to support CSP and as sugar:

<script type="module" import="foo">

[annevk]

@guybedford you can have inline script and CSP using the nonce attribute.

[caridy]

right, but I think @guybedford has a point here, adding the nonce is extra complexity compared to the old mighty script tag with src :)

[annevk]

If you do anymore than inline you'll have the src vs import debate and the processing model will get more complicated too.

[caridy]

Related notes from the discussion during last week meeting:

Script Tags:

• DH: script type = module should have roughly defer semantics, asynchronous but ordered.
• YK: before doc ready, content loaded.

Configuring Loader:

• YK: (sometimes) you need to have one block(ing script tag). this block is for configuring my loader, I don't want any scripts to load before this is done.

[dglazkov]

Other than this bug, is there a rough spec of <script type="module"> anywhere?

[caridy]

@dglazkov no, we are looking for help on this :)

[domenic]

@caridy I might be able to whip something up... I recently re-did HTML's script loading and evaluation to match ES's new semantics, so I understand the issues pretty well. The experience also confirmed my suspicions that this will be pretty intimately tied to HTML, and so probably better as a PR to HTML than as part of the loader spec; that the loader spec can continue its focus on reflective modules and configurable policies.

I'll ping you when I have something to review :)

[caridy]

@domenic 💯

[dglazkov]

🙌 🚢 🎄

[matthewp]

Is the current thinking still that this will contain a body that is a module and not a src attr?

[domenic]

I think I can manage both actually; it's almost more work to prohibit one or the other, given how HTML currently specifies <script>.