Update HTML Modules Proposed Spec changes and initial proposal document #793
Conversation
…InitializeEnvironment to create *default* binding for default export of document
… document) and set it to the *document* binding during module Evaluation. Plus some other minor corrections.
…cause error (rather than being silently coerced to type='module'
…parts being handwavy -- we've mostly progressed beyond that, I think.
| - iii\. Return *htmlModuleScript*. Note: This step is essentially validating all of the requested module specifiers. We treat a module with unresolvable module specifiers the same as one that cannot be parsed; in both cases, a syntactic issue makes it impossible to ever contemplate instantiating the module later. | ||
| - 8\. Set *htmlModuleScript*'s *record* to *result*. | ||
| - 9\. Return *htmlModuleScript*. | ||
| - Introduce a new algorithm ParseHTMLModule(*source*, *realm*, *htmlModuleScript*) as the following. |
There was a problem hiding this comment.
I think this needs to be more detailed. In particular what I think we want to do is to run the parser in a mode similar to XMLHttpRequest, whereby nothing is executed or fetched. And then once done we walk the resulting tree and execute scripts provided they meet the requirements.
It also seems reasonable to me to not require the type attribute as this is a different processing model so we can also offer developer conveniences.
There was a problem hiding this comment.
Agreed that this needs to be fleshed out more. Script execution should already be disabled because the module doc doesn't have a browsing context, but the case for fetches isn't so clear. Most things (<img>, <iframe>, etc) won't kick off fetches until moved to the main document, but it's possible something I'm not thinking of could slip through and perhaps we should head it off by enforcing a special parser mode. I'd prefer not to block all the other changes on this though so I added a TODO to investigate/deliberate this further.
The "walking through the resulting tree and executing scripts" process is already handled; see the "For each HTMLScriptElement script in document" part where we feed the scripts into the ES Modules infra (as the ScriptEntries of the HTML Module Record), so they'll be executed as part of the module graph's Evaluation phase.
Our original proposal had it such that we'd coerce non-module type scripts to module-type, but that got pushback from a few differnent folks that it would be confusing to devs and we should just make non-module scripts an error. I'm not totally sold on either direction; do you think it's worth opening a new issue thread to discuss this specifically?
There was a problem hiding this comment.
Sounds good to me. I don't think it'll be confusing long term as HTML modules are quite distinct from HTML documents in many respects.
There was a problem hiding this comment.
(And thanks for explaining the way script execution happens. That makes sense I think.)
There was a problem hiding this comment.
I belatedly opened an issue here for the question of whether to convert classic scripts to module scripts or to throw an error.
It's in the new WICG/html-modules repo for now but I'll move it if we end up not using that.
There was a problem hiding this comment.
I think we'd make faster progress here. There's 290 people watching this repository. There's 6 people watching that.
There was a problem hiding this comment.
Yup, we moved it to #798.
Edit: I guess you saw it already. :)
| 1. Let *document* be *htmlModuleScript*'s *document*. | ||
| 1. Return *document*. | ||
| - Change [fetch a single module script](https://html.spec.whatwg.org/#fetch-a-single-module-script) as follows: | ||
| - In step 9, allow `text/html` type through in addition to JavaScript. |
…tch a single module script' section to reflect that HTML Modules MIME type discussion is still ongoing.
|
Thanks Dan! (We just got the IPR block sorted...) |
I've made significant updates to the HTML Module proposed spec changes doc based on feedback here and here.
Highlights include:
• Rebased the ES changes on tc39/ecma262#1311. The most obvious change here is that HTML Module Record is now a subclass of Cyclic Module Record.
• HTML MR now inherits the concrete implementations of Instantiate() and Evaluate() from Cyclic MR (HTML MR still defines its own InnerModuleInstantiation /InnerModuleEvaluation.
• Updated ResolveExport to return a ResolvedBinding rather than the document itself. HTML MR implementations of InitializeEnvironment() and ExecuteModule() were added to create a binding named “default” and set it to the document.
• Corrected GetExportedNames to refer to HTML MR instead of Source Text MR.
• HTML Module on the HTML5 side is now a type of Script called HTML Module Script, and the existing Module Script is renamed to JavaScript Module Script.
• ScriptEntry’s [[ScriptName]] field is renamed to [[ExternalScriptURL]] and [[ModuleRecord]] is renamed to [[InlineModuleRecord]]. The [[IsInline]] field was removed.
• Fixed ResolveExport so that it the HTML Module’s default export doesn’t override a default export specified by an inline script.
• Updated and refactored “create a module script” and ParseHTMLModule to ensure that all fields are initialized for HTML Module Script and HTML MR creation.
• Edited HTML Module proposal doc to state that non-module scripts in an HTML Module will cause a parse error and make the module to fail to create, rather than being silently coerced to
type="module.There are still some questions around whether the bulk of HTML Module Record and its algorithms should actually be defined in the HTML5 spec. I expect this document to continue to evolve.