Re: [HTML Imports]: what scope to run in

On Mon, Nov 18, 2013 at 4:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> At the very least, I would like to see a way to write your
> HTML-importable document as a module. So that it runs in a separate
> global and that the caller can access exported symbols and grab the
> ones that it wants.

We had a brain-storming session about this today and I offered to
write up the conclusions.

Confusion was abound about how various details of ES6 modules work, in
part because not all corner cases have been nailed down yet, or at
least have been nailed down so recently that the message hadn't
reached everyone yet.

Our conclusion was as follows:

We want HTML imports to use the same mechanisms for dealing with name
collisions and module reuse as much as possible.

ES6 currently allows importing modules using both URLs and names. When
a names (rather than URLs) are used, there is a risk of collisions.
Specifically when a document imports two ES6 modules, A and B, both
expect a module named "apple" to be available, but expect that the
name "apple" maps to two completely different libraries. To resolve
this ES6 uses a hook which is given enough context as to allow the the
name "apple" to map to two different modules in A and in B.

We concluded that as long as ES6 only allows referring to module names
added higher up in the original document there is no race condition.
(In hindsight it's unclear to me that this was still a requirement
once we got to the end of the discussion).

We concluded that ES6 needs to use different names when referring to a
module by URL vs. by name. Otherwise it would be impossible for the
HTML prescanner to fire off network requests eagerly which is
important for performance. This does not seem to require changes to
ES6, but it does require consideration when defining how the built-in
resolver hook in browsers should behave.

We should make it a recommendation that HTML pages use <module>
elements rather than <script> elements. That way they won't
unnecessarily inject global variables into the loaded page's global
scope.

This still means that named modules in the included HTML will inject
names into the module system map (not sure if I'm getting the name
correctly here?). So this could collide with other names in other
imported HTML documents. However this isn't really any different from
the fact that element names created by different HTML imports can
collide.

Additionally, these collisions can still be dealt with using the same
ES6-provided hook. At least when the ES6 import syntax is used (though
maybe not when the system module map is accessed through API?).
However we need to make it clear that this hook takes into account
HTML imports and exposes the imported script as a context as
appropriate. (Someone that understands this hook better than me will
have to expand on the details here).

We want to introduce a property on the scope object that the <module>
elements in the imported document lives in. This property would
provide access to the imported document itself. This way we can get
rid of document.currentScript.ownerDocument hacks. (Does
document.currentScript even work in <module>?)

It would technically be possible to define that <script> elements
inside the imported documents also run inside a scope object the same
way that <module>s do. This way imported documents would be less
likely to pollute the global object of the importing page. This idea
didn't seem very popular though. (I still like it :) ).

One thing that we did discuss but that I think we never reached a
conclusion on was if imported HTML documents need to block <module>
tags in the main document. Otherwise there's a risk that named modules
introduced by the imported HTML document won't be known at the time
when name resolution happens in the main document. Whether this is a
problem or not depends on now this name resolution works. I think this
is still an outstanding question to resolve.

Ok, someone else please quickly fill in any details that I'm missing
since this stuff was complicated enough that it's plopping out of my
head already. And I'm about to go on vacation which will surely
replace all of this stuff with alcoholic beverages and sandy beaches.

Have a great thanksgiving!

/ Jonas

Received on Saturday, 23 November 2013 09:52:48 UTC