On Wed, May 28, 2014 at 4:20 PM, Ian Hickson <i...@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. >
Perhaps my explanation was unclear; I have nothing to say about browser implementation. I'll just try again. Recall that I am talking about the case where an HTML Import uses ES6 modules. The HTML Import has CSS, HTML (including IMG) and JS parts. How will the JS parts relate to ES6 modules? The simple answer is that the JS <script> tags in the Import will be the root of a dependency tree. The modules in the tree will be generic code independent of the particular CSS/HTML in the Import. This root code will be responsible for passing references bound to the CSS/HTML into the generic code in the tree. Will the JS part be an ES6 module? Could be an anonymous module but it need not be a named module imported by other JS. This root JS would only make sense with the CSS and HTML it comes with. The unit of modularity is Import here. Is there any special API for ES6 modules in HTML Imports? Not needed to get started. I'm trying to say that ES6 modules and the ES6 module system will just work in Imports. I'm not saying anything about other combinations or issues. > > > > > 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. > > I was suggesting a completely different and more pedestrian feature, the ability to imperatively load HTML Imports. (Maybe that already exists?) But I'll guess at some answers anyway: > 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? The ES6 Loader is driven, it's not the driver. Typically the Loader is driven by a <script> tag that roots the dependency tree. If the browser has a way to express that a stylesheet depends on an ES6 module, it can invoke the loader once the stylesheet arrives. But without a way to tell the JS how to refer to its special stylesheet, I don't see what we gain. To push modularity up to the next level we need JS bindings to DOM that are 'modular'. That is, the ES6 modules would not use global.foo or window.foo but mySpecialStyleSheet.foo and mySpecialStyleSheet would be only known to the module. Today we accomplish this with global functions on DOM. > 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? The Loader is very generic, it might be fun to see whether it could load something other than JS. The mechanism isn't really focused on load records. Rather, the Loader is a dependency-tree walker with some callbacks. Some callbacks are clearly defined and nicely generic (normalize, locate, fetch, translate). Some callbacks are vague, 'parse this and tell me what it imports'. Current these latter callbacks are very JS-centric. These would need work to eg parse CSS and return imports. > How about marking a load as low-priority, is > that something we can do with load records? > No, because it makes no sense in a dependency-driven loader. The root of a tree could be delayed (by the browser for example) but once we start loading, priority does not matter. jjb
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
