Webcomponents: How to handle non-type=”module” scripts in HTML Modules?

[travisleithead]

(Original OP by @dandclark)

The HTML Modules design discussed thus far forbids modules from containing non-module scripts. This allows for overall easier integration into ES modules (which would otherwise be difficult if parsing an HTML module could run script prior to module graph instantiation/evaluation), and prevents issues with parser-blocking scripts like those in HTML Imports.

However it’s not clear how this should best be achieved. Our original proposal suggested that non-module scripts in an HTML Module should be automatically converted to type=”module”. This is simple and saves the developer some typing, and is in a similar spirit as the JavaScript module behavior of silently enabling strict mode for all module scripts. The disadvantage is that it could be potentially confusing for a developer new to the feature. I first saw this concern raised here and here, and more recently on this blink-dev thread.

The alternative would be to treat a non-module script in an HTML Module as a parse error, resulting in a failure to instantiate the module. This is much more unambiguous, but devlopers might get a bit tired of needing to inlcude `type=”module” for every script element.

Since there has been discussion on this across a few different threads, I wanted to give a home to the topic here and see if some consensus can be reached.

Thoughts?

See also (https://github.com/w3c/webcomponents/pull/793)

[annevk]

As long as there's a new MIME type, I think we should embrace all these kind of simplifications. I.e., we'll use the parser (with some overrides to enforce quirks mode and UTF-8) and the resulting objects, but the processing model on the resulting tree can be somewhat novel.

[matthewp]

At first I thought removing the type="module" would be confusing but the more I thought about it, it's similar to how JavaScript modules are different from classic scripts. I don't think people find it confusing that, for example, a JavaScript module's top-level variables aren't globally accessible. So I think similarly, HTML modules can remove some of the legacy defaults such as this and #797, and possibly more.

[ruphin]

A side-effect of removing the type="module" declarations from scripts in an html module file is that the html file itself may become invalid (when loaded directly as an HTML file, not as a module), because in this scenario the scripts will not be interpreted as module scripts. By going through with this, you are essentially creating two classes of *.html files; one that may be opened directly in a browser and one that may only be loaded as a module.

I'm not sure how much of a concern that is, but I think it is worth considering.

[annevk]

That's going to happen either way, and that's also why there's #742.

[joeldenning]

I just created a PR https://github.com/systemjs/systemjs/pull/2011 that adds full support for polyfilling HTML modules.

In it, I had to take a stance on handling <script> elements that don't have a type="module". My current initial implementation throws an error.

Any update on this issue?

[dandclark]

This question is still not 100% settled, so to be forward-compatible I think your initial decision to throw an error for non-module scripts is best.