Integrating the Webs' dependency systems

Matthew Robb matthewwrobb at gmail.com
Wed May 28 16:26:57 PDT 2014


Perhaps it's too cumbersome to use the System loader to specify the
business logic for the browsers dependency loading/registry etc. Maybe a
low-level browser spec needs to exist that a light System object could
eventually defer to. This almost seems easier and more straight forward
(requiring less cross-spec coordination) to make progress on.


- Matthew Robb


On Wed, May 28, 2014 at 4:20 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 28 May 2014, John Barton wrote:
> > >
> > > Is the list that Juan described (see below) the list you had in mind?
> >
> > Yes.
>
> Cool, thanks. (It would be great if this list could be more explicitly in
> the spec, for ease of reference.)
>
>
> > > > > > HTML Imports offers a middle ground: while it is declarative it
> > > > > > is also modular so the complexity can be divided and conquered.
> > > > > > I don't think it requires script so it is an alternative
> > > > > > starting point.
> > > > >
> > > > > My goal here is for us to make sure that ES6 modules and HTML
> > > > > Imports end up specified using the same dependency mechanism.
> > > >
> > > > I thought this would just work. HTML Imports will have <script> tags
> > > > and those <script> tags will invoke System.import() and thus use the
> > > > same dependency mechanism.
> > >
> > > Well, something in the HTML spec has to "invoke System.import()" and
> > > all that jazz, right? That's what I'm trying to make sure we spec
> > > here.
> >
> > The document imported by HTML Import would depend on some ES6 modules
> > and it would contain some CSS and HTML. Knitting these together would
> > require some JS execution which would compute references to the CSS/HTML
> > and pass them to ES6 code for processing. That bit of glue code would
> > probably live in the Imported document. We can have examples but I don't
> > see how to spec it unless there are Import-specific functions for
> > obtaining the references to the content from the Import.
>
> To import an HTML Import doesn't require any script, it's just:
>
>    <link rel=import href="...">
>
> The browser's implementation of this would presumably go through the
> machinery that System.import() goes through, right? I mean, we don't want
> to require script just to use HTML imports. We certainly don't want to
> require that the author provide a script that extends Loader just to be
> able to use <img>, but we presumably want <img> to eventually go through
> the same machinery.
>
> Or maybe not? I'm not sure I really understand whether there is agreement
> that the ES6 module system should be able to work with the rest of the
> platform's loading and dependency system.
>
>
> > > > The reverse however, where System could have a dynamic effect
> > > > similar to static HTML Imports *and* use the same dependency
> > > > mechanism for the CSS/HTML is not as far as I know possible short of
> > > > adding Import tags to the document. This would be nice to have, but
> > > > requires coordination with HTML Import.
> > >
> > > Right, that's what I'm trying to do.
> >
> > This would seem to require Web-specific extensions to System as I
> > mentioned before.
>
> Ok. I'm not really sure how to extend the ES6 module system in a way that
> won't stomp on this working group. How do I (at the spec level) tell the
> ES6 module system that it should not evaluate a particular module until
> some non-script resource, e.g. a style sheet, is available? It seems like
> it needs a closer integration with load records than the APIs would
> enable. For example, would we be able to hook the CSS @import loading
> mechanism into load records? How about marking a load as low-priority, is
> that something we can do with load records?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140528/246b8e9b/attachment.html>


More information about the es-discuss mailing list