Re: [w3c/webcomponents] Update HTML Modules Proposed Spec changes and initial proposal document (#793)

dandclark commented on this pull request.



>      - b\. If *url* is failure, then:
       - i\. Let *error* be a new TypeError exception.
-      - ii\. Set *htmlModule’s* *parse error* to *error*.
-      - iii\. Return *htmlModule*.  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 *htmlModule’s* *record* to *result*.
-  - 9\.   Return *htmlModule*.
-- Define ParseHTMLModule(*source*, *realm*, *htmlModule*) as roughly the following.  TODO Given that we define  HTML Module Record in ES6, should this function be defined over there?  We’re using the HTML5 parser though...
-  - 1\. Let *record* be a new HTML Module record that this algorithm will subsequently initialize. 
-  - 2\. Run the HTML5 parser on source to obtain the result *document*.
-  - 3\. Set *record*.[[HostDefined]] = *htmlModule*.
-  - 4\. For each HTMLScriptElement *script* in *document*:
-    - a\. Let *se* be a new ScriptEntry record (see definition in ES6 changes above).
+      - ii\. Set *htmlModuleScript*'s *parse error* to *error*.
+      - 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.

Agreed that this needs to be fleshed out more.  Script execution should already be [disabled](https://html.spec.whatwg.org/#concept-n-noscript) 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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/pull/793#discussion_r256970506