-
Notifications
You must be signed in to change notification settings - Fork 371
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to handle non-type=”module” scripts in HTML Modules? #798
Comments
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. |
At first I thought removing the |
A side-effect of removing the I'm not sure how much of a concern that is, but I think it is worth considering. |
That's going to happen either way, and that's also why there's #742. |
I just created a PR systemjs/systemjs#2011 that adds full support for polyfilling HTML modules. In it, I had to take a stance on handling Any update on this issue? |
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. |
(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?
The text was updated successfully, but these errors were encountered: