Integrating the Webs' dependency systems

Ian Hickson ian at
Tue May 27 15:04:49 PDT 2014

On Fri, 23 May 2014, Garrett Smith wrote:
> And can we change "needs=" back to "depends="?

I haven't gotten as far as figuring out what the API should look like, so 
it's probably too early to bikeshed specific attribute names. :-)

> > The basic theme of <script needs=""> is making it possible for 
> > resources (probably more than just scripts) depend on each other and 
> > delay loads until they are needed. For example, being able to say 
> > "this script shouldn't download yet.
> Shouldn't download or shouldn't be evaluated?


> > When it is needed, though, it should also download and apply this 
> > style sheet,
> Stylesheets, too? :-)

Anything, ideally.

On Fri, 23 May 2014, Matthew Robb wrote:
> On Fri, May 23, 2014 at 5:04 PM, Ian Hickson <ian at> wrote:
> >
> > Could you elaborate on what it would mean for a module to import a 
> > template or style sheet? I'm not super-familiar with ES6 modules yet 
> > so I'm not sure exactly how this would manifest syntactically.
> So my (albeit limited) understanding of ES6 Loader is that it is up to 
> the environment to create a relevant implementation. This has been 
> referred to as the System global loader. What I am proposing is that in 
> the browser, dependencies for things like modules, components, 
> templates, stylesheets, are all important for different reasons and in 
> each of those contexts.
> So the browser's System loader should have a method of loading any of 
> these common browser dependencies. The only thing left to decide is what 
> the exports of non-modules would be. For components it seems obvious by 
> default they would export their components by global name.
> document.register("x-foo", ...);
> and
> import { XFoo } from "path/to/component";

Ah so the ES6 "import" statement can import anything, even things that 
aren't ES6 modules?

It would certainly be cool if that was possible.

> But you could go further and give components the ability to represent 
> modules in script explicitly. You might also want to export all linked 
> components from within a given component by default.
> <link rel="imports" href="x-foo-button.html"/>
> <module>
> import { XFooButton } from "x-foo-button.html";
> </module>
> In the above case you would either implicitly or explicitly be able to do
> <module>
> export XFooButton as "x-foo-button.html";
> </module>
> I hope any of what I just typed is understandable, if not I will try to 
> put it in better words when I have more time.

Well presumably we wouldn't want to require that people write script to 
add things to the dependency system, right? I mean, we presumably would 
want the markup to also do the "export" step implicitly.

On Fri, 23 May 2014, Kevin Smith wrote:
> >
> > A script could then tell the system to add this <img> element / 
> > HTMLImageElement object as one of the dependencies for a script it was 
> > injecting, so that that script doesn't run until the image is 
> > downloaded. (Doing this, assuming the script is then told to run 
> > immediately, would be another way of telling the image it was needed. 
> > That's one reason to have the dependency system be abstract like this: 
> > it lets different parts of the platform participate by just exposing a 
> > generic interface, so that Web authors think we designed this all as 
> > one coherent whole.)
> Do you think that, in principle, a resource of a given type should be 
> able to declaratively specify a dependency upon a resource of a 
> different type?

I don't think this is a general principle, e.g. I don't think it makes 
much sense for us to extend the PNG spec to integrate with this.

But there are certainly multiple parts of the platform that want to 
declare dependencies on and from different resource types.

> So, for example, an ES module might hypothetically declare a dependency 
> upon a CSS stylesheet and vice versa?

If that is something that ES wants to be able to declare, I would be happy 
for us to support it.

> I think *the* critical attribute that such a dependency system must have 
> is a universal syntax and semantics for identifying resources, across 
> all resource types.  In other words, all resources must be identified by 

I don't think a URL is the right way to identify everything. Many things 
in the Web platform that you could legitimately want to depend on don't 
have a URL. For example, a promise, or an inline <script> block, or an 
HTML <video> element (the latter in particular would have several URLs, 
the whole point would be to depend on the element so that things only 
happen once that element has figured out which file it wants to play and 
is ready to do so).

On Tue, 27 May 2014, John Barton wrote:
> On Fri, May 23, 2014 at 5:04 PM, Ian Hickson <ian at> wrote
> >
> > What/where would be the best place to define such a system,
> Github.

I really meant which specification. As I see it we have four obvious 
places where we could concretely define the Web's dependency system:

 - the ES spec
 - the HTML spec
 - the Fetch spec
 - some new spec

(HTML Imports will eventually become merged with the HTML spec, so I 
haven't listed that separately.)

Putting it in ES would be fine by me (less work for me!). (I don't think 
it's a problem for HTML to depend on ES for something like this, even if 
not all browsers implement ES -- for example, the HTML spec already 
defines things in terms of the DOM and CSS specs, even for browsers that 
don't implement the DOM API or CSS. It just means the end-result should be 
as if the underlying spec was implemented, even if the rest of that 
underlying spec isn't implemented.)

So, what should we do here? Do people agree that the model I described 
here is the model that covers everything we need here?:

What would be the best spec to put this in? How should we ensure that all 
the specs that are to use this actually do use this? What interfaces 
should we have between the specifications to do this?

> > and how would we hook all the specs together to use it?
> Define a "System" object for ES6 that implements the ES6 Loader API and 
> extends it to dynamically load CSS and HTML.

Can you elaborate on this? I don't really follow.

On Tue, 27 May 2014, John Barton wrote:
> The most important problem to iron out with HTML Import + ES6 Loader is 
> the timing confusion. Both systems use a combination of asynchronous and 
> blocking-for-dependents loading.

Right, that's why I think we should just have one processing model which 
both specs hook into. That way there'd only be one system using a 
combination of asynchronous and blocking-for-dependents loading.

On Tue, 27 May 2014, Kris Kowal wrote:
> It would be lovely if HTML could be trained to resolve URL's through the 
> module system.

By "HTML" here I presume you mean the underlying Fetch mechanism. Could 
you elaborate on exactly how this would work? Would this be in the layer 
before or after Service Workers?

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the es-discuss mailing list