Re: [w3c/webcomponents] HTML Modules (#645)

- @Jamesernator I’m hesitant to complicate the model by including non-synchronous classic scripts unless we're sure we have a compelling use case.  It is already a limitation of ES6 script modules that they can’t import classic scripts, so if we consider this to be a problem it’s probably one that we should try to address in a general sense for both HTML and script modules.
Sidenote: your comment prompted me to think of another interesting case: `<script type=”module” async>` in an HTML Module.  Per [spec](https://html.spec.whatwg.org/#attr-script-async) I guess we’re free to execute async scripts pretty much whenever we want, but I need to think about whether this has any tricky implications that we need to watch out for.

- @caridy Yeah, I like option A best too ("throw an error for the HTML module if it is found during parse-time to contain a non-module-type script element").

- @tomalec I hadn’t seen the display locking proposal, this does seem like an interesting potential alternative to the dynamic import() idea for FOUC prevention.

- @littledan My previous comment elided our proposed default export behavior.  Our thinking for default exports is this:
    -  If no inline scripts specify a default export, set the HTML import’s document as its default export.
    - If one inline script specifies a default export, pass that through as the HTML module’s default export.
    - If multiple inline scripts specify a default export, throw an error during module instantiation – similar to what happens when a single module script tries to use multiple default exports. 



-- 
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/issues/645#issuecomment-435432193