Referencing modules loaded by HTML Imports.

John Barton johnjbarton at google.com
Mon Aug 18 15:56:18 PDT 2014


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:
>
>    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
"<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140818/5626a564/attachment.html>


More information about the es-discuss mailing list