Referencing modules loaded by HTML Imports.
On Mon, 18 Aug 2014, John Barton wrote:
On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson <ian at hixie.ch> wrote:
To avoid overly spamming the list I've coallesced my responses to various threads over the weekend into this one e-mail.
I really think this makes the discussion more difficult to follow and certainly more difficult to participate in.
Apologies, I'm not familiar with this lists' conventions.
Now, in the main page, you reference the HTML import:
<link rel=import href="foo.html">
Now how would you refer to the modules? We can't have #b refer to it, since the scope of IDs is per-document, and the import has a separate document.
Separate document implies separate JS global: each needs its own Loader. So the rest of the questions aren't needed.
HTML imports definitely need to expose modules across documents. Are you saying this requires changes to ES6 to support? What changes would we need?
You need to give more details about such requirements. What is the runtime relationship between Imports and other documents? I assume the Import is providing some state that ends up in the importer but then you are saying these are different documents.
HTML imports and regular documents share a Window object, but have separate Documents objects. You can find out more about them here:
w3c.github.io/webcomponents/spec/imports
They are "shortly" to be merged into the HTML spec proper; doing so is mostly just blocked on my work trying to integrate HTML with ES6's module loader so that we don't end up with multiple redundant dependency systems.
On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson <ian at hixie.ch> wrote:
Now, in the main page, you reference the HTML import:
<link rel=import href="foo.html">
Now how would you refer to the modules? We can't have #b refer to it, since the scope of IDs is per-document, and the import has a separate document.
...
HTML imports and regular documents share a Window object, but have separate Documents objects. You can find out more about them here:
If they share a Window object then they should share a Loader, but they may have different baseURLs. So for you example above we write eg.
import {b} from "./b";
because the scripts in the HTML import will have names relative to the same default baseURL as the main document. So I guess URL space is like
example.com/index.html, example.com/foo.html, example.com/b.js
I suppose it would be more common for the component to be in a subdirectory, eg
example.com/index.html, example.com/foo/theFoo.html, example.com/foo/b.js
so the import would be
import {b} from "./foo/b";
I think we could also imagine that such an import declaration could be used without the HTML Import declaration. The fetch() call will ask for "<baseURL>/foo/b.js" and the server will say "hey that's in an HMTL Import"
and serve text/html. The fetch() hook will have to detect this and process the HTML Import, then continue with the loading process. This much I'm just making up.
jjb
Would there be any problems treating the html import as a virtual module itself. Giving all scripts inside the sub document the module context object as its this binding? Then to do any additional loading you'd need to do this.import().
I think that only makes sense if 'this.import()' worked for script-tags-marked-as-modules in general. If the general case supported it, then it should just work for HTML imports.
OTOH, I think System.import() is clearer.
jjb
On Mon, 18 Aug 2014, John Barton wrote:
On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson <ian at hixie.ch> wrote:
Now, in the main page, you reference the HTML import:
<link rel=import href="foo.html">
Now how would you refer to the modules? We can't have #b refer to it, since the scope of IDs is per-document, and the import has a separate document.
If they share a Window object then they should share a Loader, but they may have different baseURLs. So for you example above we write eg.
import {b} from "./b";
because the scripts in the HTML import will have names relative to the same default baseURL as the main document.
I don't understand. Why would "b" refer to a script in the module?
Suppose you have two imports in index.html:
<link rel=import href="foo.html"> <link rel=import href="bar.html">
...and foo.html and bar.html both have this structure:
<!DOCTYPE HTML> <script type=module id=mod1> ... </script> <script type=module id=mod2> ... </script>
How should an import statement in index.html refer to the id=mod1 module in foo.html? How about the id=mod1 module in bar.html? How about the id=mod2 module in bar.html?
(All the files are in the same directory.)
I think we could also imagine that such an import declaration could be used without the HTML Import declaration. The fetch() call will ask for "<baseURL>/foo/b.js" and the server will say "hey that's in an HMTL Import" and serve text/html. The fetch() hook will have to detect this and process the HTML Import, then continue with the loading process.
That's basically what everything I've been e-mailing the list about is intended to support.
On Mon, 18 Aug 2014, Matthew Robb wrote:
Would there be any problems treating the html import as a virtual module itself. Giving all scripts inside the sub document the module context object as its this binding? Then to do any additional loading you'd need to do this.import().
I'm not sure what this means. Presumably though the browser should take care of this, the author shouldn't have to call this.import() or anything manually.
On Tue, 19 Aug 2014, John Barton wrote:
OTOH, I think System.import() is clearer.
Not sure how this applies here.
On Tue, Aug 19, 2014 at 4:22 PM, Ian Hickson <ian at hixie.ch> wrote:
On Mon, 18 Aug 2014, John Barton wrote:
I think we could also imagine that such an import declaration could be used without the HTML Import declaration. The fetch() call will ask for "<baseURL>/foo/b.js" and the server will say "hey that's in an HMTL Import" and serve text/html. The fetch() hook will have to detect this and process the HTML Import, then continue with the loading process.
That's basically what everything I've been e-mailing the list about is intended to support.
While I think this topic -- triggering an HTML Import from a JS import -- is interesting and potentially useful, there is no new syntax or I see no Loader implementation changes needed for this to work.
Composing HTML Imports with System.import() has issues because the import is async, see groups.google.com/forum/#!topic/polymer-dev/gbWgeLNnMrE
jjb
On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson <ian at hixie.ch> wrote:
I really think this makes the discussion more difficult to follow and certainly more difficult to participate in.
You need to give more details about such requirements. What is the runtime relationship between Imports and other documents? I assume the Import is providing some state that ends up in the importer but then you are saying these are different documents.