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 <[email protected]> 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. `._.-(,_..'--(,_..'`-.;.' >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
