Re: Referencing modules loaded by HTML Imports.
On Tue, Aug 19, 2014 at 4:22 PM, Ian Hickson 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 > > "/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 https://groups.google.com/forum/#!topic/polymer-dev/gbWgeLNnMrE jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Referencing modules loaded by HTML Imports.
On Mon, 18 Aug 2014, John Barton wrote:
> On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson wrote:
> > > > > >
> > > > > > Now, in the main page, you reference the HTML import:
> > > > > >
> > > > > >
> > > > > >
> > > > > > 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:
...and foo.html and bar.html both have this structure:
...
...
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
> "/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.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Referencing modules loaded by HTML Imports.
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, Aug 18, 2014 at 6:23 PM, 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().
> On Aug 18, 2014 6:56 PM, "John Barton" wrote:
>
>>
>>
>>
>> On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson wrote:
>>
>>>
>>>
>>> > > > > Now, in the main page, you reference the HTML import:
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > 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:
>>>
>>>http://w3c.github.io/webcomponents/spec/imports/
>>
>>
>> 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
>>
>> http://example.com/index.html
>> http://example.com/foo.html
>> http://example.com/b.js
>>
>> I suppose it would be more common for the component to be in a
>> subdirectory, eg
>>
>> http://example.com/index.html
>>http://example.com/foo/theFoo.html
>> http://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
>> "/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
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Referencing modules loaded by HTML Imports.
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().
On Aug 18, 2014 6:56 PM, "John Barton" wrote:
>
>
>
> On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson wrote:
>
>>
>>
>> > > > > Now, in the main page, you reference the HTML import:
>> > > > >
>> > > > >
>> > > > >
>> > > > > 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:
>>
>>http://w3c.github.io/webcomponents/spec/imports/
>
>
> 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
>
> http://example.com/index.html
> http://example.com/foo.html
> http://example.com/b.js
>
> I suppose it would be more common for the component to be in a
> subdirectory, eg
>
> http://example.com/index.html
> http://example.com/foo/theFoo.html
> http://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
> "/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
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Referencing modules loaded by HTML Imports.
On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson wrote:
>
>
> > > > > Now, in the main page, you reference the HTML import:
> > > > >
> > > > >
> > > > >
> > > > > 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:
>
>http://w3c.github.io/webcomponents/spec/imports/
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
http://example.com/index.html
http://example.com/foo.html
http://example.com/b.js
I suppose it would be more common for the component to be in a
subdirectory, eg
http://example.com/index.html
http://example.com/foo/theFoo.html
http://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
"/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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: 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 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: > > > > > > > > > > > > > > > > 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: http://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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
