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

- @littledan, @caridy : Thus far I’d been assuming we’d change the semantics of `<script>s` in an HTML Module such that they would just implicitly be treated as `type="module"`, however you raise a good point that this could be confusing.  In a way though this is similar to the existing state of the world with script modules, where devs must be aware that the same js file might be parsed with strict mode depending on whether it is loaded as a module or not.  Similarly they should expect different semantics when an HTML file is loaded as a module.

  If we want to change this though I see three possible alternatives: (A) Throw an error for the HTML module if it is found during parse-time to contain a non-module-type script element, with the result that no scripts in the HTML module will run, (B) wait until execution time to throw the error such that module scripts coming earlier in the HTML module get to run and those after do not,  or (C) simply don’t run an HTML module’s non-module-type scripts, but allow the other scripts to run and don’t throw an error.

  Whichever answer we go with, a console warning is probably warranted for each non-module-type script affected by this.

- @littledan re: multiple script tags exporting in the same HTML Module:  I think that support for multiple scripts still fits neatly into the semantics of ES6 module import/export.  An HTML Module with multiple `<script>` elements would basically do the equivalent of this:
`export * from inlineScript0;`
`export * from inlineScript1;`
`…`

  This should not require much additional plumbing versus exporting the contents of a single `<script>` since the current ES6 modules implementations already have the mechanisms in place to support multiple `export * from …` statements.   We can even use the existing semantics for dealing with export name collisions etc. between multiple `<scripts>`.  Though it’s possible I’m missing something here; I’m not really against limiting it to a single `<script>` if this turns out to be problematic.

- @tomalec, @matthewp: Good point about the FOUC issue.  This seems to be a problem built in to the ES6 module design in general, e.g. if I want to define a custom element today in a script type=”module” then I would face the same complications.  Now as we expand modules to support HTML content the issue will apply there as well.  As long as module-graph-loading can’t block the parser I’m not sure we have a satisfactory answer for those who want modules but also want their content to block first-load.  Any solution/workaround here for script modules seems to me that it should apply to HTML modules and vice versa.  One possibility that I am pondering is the use of dynamic import(), since this can be originated from non-module scripts and can thus be used to block the parser when needed.

-- 
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-433238619