- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 23 Aug 2014 00:44:23 +0000 (UTC)
- To: "whatwg@whatwg.org" <whatwg@whatwg.org>
When I last looked at preloading scripts, it was pointed out to me that
the Web Perf WG had some work ongoing in this space, so I decided to let
them take care of it. However, nothing much seems to be happening there,
and so I'm looking at this again. It's also been pointed out that limiting
this to just scripts preloading maybe taking too narrow a view, and that
we should also consider preloading and deferring loading of other
resources, such as images, style sheets, and so forth.
I will start by looking at use cases again, then go through some of the
feedback on the last proposal I'd made in this space, and then make a new
proposal intended to address the use cases and feedback.
On Fri, 15 Aug 2014, Ben Maurer wrote:
>
> [Use-case F:] A website has a page where media is the primary content.
> It would like to make sure that media is downloaded before JS [e.g.
> flickr, youtube, facebook photos]
>
> [Use-case G:] A website knows there's a piece of Javascript code that
> the user might need if they click on a part of the page. The developer
> would like to have the user download it, but not at the expense of other
> resources.
>
> [Use-case H:] A website is prefetching photos in a photo album and would
> like to make sure these images are lower priority than images the user
> is actually viewing.
On Mon, 28 Jul 2014, Ben Maurer wrote:
>
> [Use-case I:] Facebook uses an automated pipeline to decide what CSS/JS
> files to package together. If we could pass a custom header in the
> request for a CSS file (for example: what part of the page caused that
> file to be loaded) we could use this information in our packaging system
> to make smarter decisions.
On Tue, 22 Jul 2014, Ben Maurer wrote:
>
> [Use-case J:] The way we render pages at Facebook [is essentially that
> we] flush sections of HTML with a list of CSS and JS dependencies for
> each section. The HTML is only rendered once these resources are loaded.
> [Use-case K:] We have a few other use cases for this type of dependency
> (for example, we have a method where you can say "call this callback
> once resources X, Y and Z are requested").
On Tue, 3 Sep 2013, Ryosuke Niwa wrote:
>
> [Use-case L:] A web page wants to load and execute a script widget.js if
> the script is already cached in the browser. However, it wants to load
> other essential assets such as images first if it's not already in the
> cache except as long as the user had not started interacting with the
> parts of the page that require widget.js.
On Tue, 18 Mar 2014, Jonas Sicking wrote:
>
> [Use-case M:] Being able to specify that an image/video should only be
> downloaded "on demand" (aka "lazily"), i.e. when it's in view, or about
> to be in view. Use case is both to lower bandwidth in cases of long
> pages where the user doesn't always scroll to the bottom, as well as
> make sure to fill the network pipe with the most important resources
> first.
> [Use-case N:] Being able to specify that a stylesheet should not block
> rendering. Use case is to preload stylesheets that will be used by
> content that isn't rendered in the initial view, but that might be
> rendered later.
> [Use-case O:] Being able to specify some form of prioritization for
> resources like (non-blocking) stylesheets, (non-blocking) <script>s,
> images, video, iframes etc. Use case is making sure to fill the network
> pipe with the most important resources first. Possibly a simple
> prioritization like "needed for initial rendering/not needed for initial
> rendering" is enough, possibly there are needs for more finegrained
> prioritization like "needed for initial rendering/needed for page
> feature X that is commonly used, needed for other".
On Fri, 30 Aug 2013, Yoav Weiss wrote:
>
> [Use-case P:] download dynamic page components (e.g. maps) only on
> larger devices.
On Wed, 10 Jul 2013, Kyle Simpson wrote:
>
> [Use-case Q:] I am dynamically loading one of those social widgets that,
> upon load, automatically scans a page and renders social buttons. I need
> to be able to preload that script so it's ready to execute, but decide
> when I want it to run against the page. I don't want to wait for true
> on-demand loading, like when my user clicks a button, because of the
> loading delay that will be visible to the user, so I want to pre-load
> that script and have it waiting, ready at a moment's notice to say "it's
> ok to execute, do it now! now! now!".
> [Use-case S:] One CMS plugin wants to load "A.js" and "B.js", where B
> relies on A. Both need to load in parallel (for performance), but A must
> execute before B executes. I don't control A and B, so changing them is
> not an option. This CMS plugin [wants] to wait for some
> user-interaction, such as a button click, before executing the code. We
> don't want there to be any big network-loading delay visible to the user
> between their click of the button and the running of that plugin's code.
>
> Another CMS plugin on this same page wants to load "A.js", "C.js", and
> "D.js". This plugin doesn't know or care that the other plugin also
> requests "A.js". It doesn't know if there is a script element in the
> page requesting it or not, and it doesn't want to looking for it. It
> just wants to ask for A as a pre-requisite to C and D. But C and D have
> no dependency on each other, only a shared dependency on A. C and D
> should be free to run ASAP (in whichever order), assuming that A has
> already run [once] some user-interaction that initiates the load of A,
> C, and D. This user interaction may be before the other plugin requested
> A, or after it requested A.
>
> "A.js" can be requested relatively (via a <base> tag or just relative to
> document root) or absolutely, or it might be requested with the
> leading-// protocol-relative from, taking on whatever http or https
> protocol the page has, whereas other references to it may specify the
> prototcol.
>
> These plugins can't guarantee what ID's or classes they use are reliably
> unique without undue processing burden.
> [I've trimmed the text Kyle wrote here, but also implicit in his
> description, as I understood it, was that A.js should only run once even
> if both plugins tried to load it.]
> [Use-case T:] I have two different calendar widgets. I want to pop one
> of them up when a user clicks a button. The user may never click the
> button, in which case I don't want the calendar widget to have ever
> executed to render. [...]
>
> It'd be nice if both calendar widgets were built sensibly so that
> loading the code didn't automatically render. One of them IS, the other
> is unfortunately mis-behaving, and it will render itself as soon as its
> code is run. [...]
>
> Furthermore, these two widgets are not "equal". Perhaps one is better
> for smaller browser window sizes, and the other is better for larger
> browser windows. [...]
>
> Regardless, the point is, there's run-time conditions which are going to
> determine if I want to execute calendar widget A or B, or maybe I never
> execute either. But I want them both preloaded and ready to go, just in
> case, so that if the user DOES need one, it's free and ready to execute
> with nearly no delay, instead of having to wait to request as I would
> with only on-demand techniques.
> [Use-case U:] I have a set of script "A.js", "B.js", and "C.js". B
> relies on A, and C relies on B. So they need to execute strictly in that
> order. [Now], imagine they progressively render different parts of a
> widget. [...] I only want to execute A, B and C once all 3 are preloaded
> and ready to go. It's [...] about minimizing delays between them, for
> performance PERCEPTION.
>
> [For example, one of them might start playing a video, and another might
> introduce the <canvas> slides for that video. You want all of the
> relevant scripts to be run at once, so there's no point where the page
> has a <video> element but doesn't have the <canvas>.]
On Thu, 11 Jul 2013, Kyle Simpson wrote:
>
> [Use-case V:] you have a string of scripts ("A.js", "B.js", and "C.js")
> loading which constitute a dependency chain. A must run before B, which
> must run before C. However, if you detect an error in loading, you stop
> the rest of the executions (and preferably loading too!), since clearly
> dependencies will fail for further scripts, and the errors will just
> unnecessarily clutter the developer console log making it harder to
> debug.
> [Use-case W:] some developers have even requested to be able to stop the
> chain and prevent further executions if the script loads, but there's
> some compile-time syntax error or run-time error that happens during the
> execution. For them, it's not enough for B to simply finish loading
> successfully, but that it must fully execute without error.
On Sun, 14 Jul 2013, Kornel Lesiński wrote (trimmed):
>
> [Use-case X:] not all dependencies are JS files, e.g. authors use
> plugins to load template files, JSON, images, etc.
>
> [Use-case Y:] not all dependencies are usefully satisfied immediately
> after their JS file is loaded, e.g. some libraries may need asynchronous
> initialization.
>
> [Use-case Z:] Another common kind of dependency scripts have is presence
> of certain element in the DOM, e.g. `dropdown-menu.js` may require `<nav
> id="menu">` to be in the document _and_ have its content fully parsed
> before the script can run.
On Tue, 27 Aug 2013, Ian Hickson wrote:
>
> Jake also mentioned these requirements:
>
> | - Provides an adoption path for browsers that don't support the new
> | feature (happy for the fallback to be blocking document-order
> | execution)
> | - Is discoverable by pre-parsers (so async=false and old-IE's
> | readystate methods aren't enough)
>
> And Kyle mentioned this scenario that we need to handle as well (not
> strictly a use case, more a variant on the above use cases):
>
> > I want to preload a script which is hosted somewhere that I don't
> > control caching headers, and to my dismay, I discover that they are
> > serving the script with incorrect/busted/missing caching headers.
> Incidentally, I don't think the use case is or should be "make it
> possible to write a performant script loading library". I think the use
> case should be more like "make it unnecessary to ever write a script
> loading library".
Bearing those use cases and requirements in mind, here's the feedback
received since the last proposal:
On Thu, 29 Aug 2013, Jake Archibald wrote:
> On 27 August 2013 22:55, Ian Hickson <ian@hixie.ch> wrote:
> > On Tue, 9 Jul 2013, Bruno Racineux wrote:
> > >
> > > I would also strongly favor restoring the previous spec portion of
> > > 'defer' which allow to have defer on inline script blocks (i.e. if
> > > the src attribute is not present). I don't know why this html4
> > > functionality was removed from html5?
> >
> > Well, primarily because basically nobody implemented it, but also,
> > because it's not clear what the point is. Why would you need it?
>
> I like my scripts to be inert, as in have no impact on the page (like
> jquery). I use a small inline script to start the work needed for that
> page, meaning I know the starting point for all JS interacting with the
> page is somewhere in an inline script. This is much easier to maintain
> than scripts that trigger themselves ondomready depending on what they
> see in the DOM.
I agree entirely. But how does this impact defer=""? If the script has no
effect, it really don't matter when it's run.
Or are you saying you want an inline script to be deferred, so that it
runs after all the external deferred scripts?
Given legacy implementations and back-compat needs I doubt we could do
this with defer="" at this point, but:
> In your proposal, does this work?…
>
> <script src="whatever.js" whenneeded></script>
> ...
> <script needs="whatever.js">
> activateTheAlmightyWebsockets();
> </script>
Yeah, we should support that, certainly.
> > On Wed, 10 Jul 2013, Jake Archibald wrote:
> > >
> > > If "dependencies" took a CSS selector it could be:
> > >
> > > <script dependencies=".cms-core" src="cmd-plugin.js"></script>
> > >
> > > Now the number of scripts with class "cms-core" can change between
> > > versions of the CMS but the plugin still waits for them all. No ID
> > > generation needed.
> >
> > Using a selector is an interesting idea.
> >
> > It makes it harder to detect and prevent loops, but not fatally so.
>
> I'm not sure it's possible to get into loops with this. I imagined
> dependency resolution to happen once, on element creation or adding to
> document (whichever happens latest). So with:
>
> <script src="a.js" needs="script[src=b.js]"></script>
> <script src="b.js" needs="script[src=a.js]"></script>
>
> …the first script would have zero dependencies, because the selector
> matches zero elements. The second would depend on the first, so the
> execution order is a.js, b.js. The thing I like about the selector thing
> is you can very easily get (almost) async=false behaviour:
>
> <script src="a.js" needs="script"></script>
> <script src="b.js" needs="script"></script>
> <script src="c.js" needs="script"></script>
Ah. A one-off selector matching seems less interesting.
With real-time matching, you could do things like:
<script src="fancytextarea.js" needs="textarea"></script>
...and have it get invoked once a textarea appeared, or some such. It
would depend on exactly how the semantics were set up, I guess.
> execute() should return a promise that resolves when the script
> successfully downloads and executes.
I guess we could do that. It's not clear to me what the benefit is. None
of the use cases particularly seem to need it.
> Also, should there be an event on the script element when the script has
> downloaded, but not executed (like IE used to have)?
Similarly here. What's the use case?
> > <script> elements also get a new needs="" attribute, which takes a list
> > of URLs. A <script> won't run (even if you call execute()) until all the
> > <script src=""> elements referenced by its needs="" attribute are
> > themselves ready to run. For example:
> >
> > <script src="bbbbb.js" needs="aaaaa.js"></script>
> > <script src="aaaaa.js" async></script>
> >
>
> It seems weird to refer to "needs" by url, but still require script
> elements for those needs, I'd rather use IDs (or selectors yey!).
IDs require more markup to do the same thing:
<script src="bbbbb.js" needs="a"></script>
<script src="aaaaa.js" id="a" async></script>
Selectors require more markup or more complex selectors:
<script src="bbbbb.js" needs="#a"></script>
<script src="aaaaa.js" id="a" async></script>
<script src="bbbbb.js" needs="script[src='aaaaa.js']"></script>
<script src="aaaaa.js" async></script>
Not clear to me that either are a win.
Using URLs has the big advantage that it means you can do this logic
across import documents, too, which will become more interesting when Web
components are used more.
Having said that, IDs and Selectors do have a few of advantages that
aren't obvious in the above code: they let you reference elements other
than scripts, and they avoid one confusing aspect of URLs which is that
people interpret the following as actually executing a.js even if there's
no <script> that mentions a.js in its src="":
<script src="b.js" needs="a.js"></script>
Also, IDs mean you can have dependencies on local script blocks.
One _disadvantage_ of IDs, though, is that they don't let us dedupe
multiple scripts with the same URL as easily. Though maybe the solution
there is for there to be some attribute (e.g. whenneeded="") that applies
a new rule: if this <script> refers to a resource already mentioned by
another <script>, then ignore this <script>, or make references to this
<script> defer to the previous one.
Then again, for scripts, maybe we can just tell people to use modules?
One thing worth bearing in mind is that if we use a different syntax for
"import" in ES6 modules than for needs="" (or whatever we call it) in
HTML, then you won't be able to simply promote "import" to the attribute,
you'll have to manually figure out what it means.
> Also, I'm not sure we need to deal with the case above, where the script
> with the dependency appears in the DOM prior to the script it depends
> on. Avoiding this avoids the circular dependency problem (see my
> selector example above)
Circular dependencies are relatively easy to break.
Not having requirements on order means that you can import multiple
documents that each invoke script, and not have to worry about getting the
order exactly right.
> Does a script with "needs" but not "async" block rendering? I hope not.
needs="" in this proposal implies async-ish behaviour. We want to move
away from anything that blocks.
On Thu, 29 Aug 2013, Glenn Maynard wrote:
> >
> > <script whenneeded="jit"> is a special mode where instead of running
> > once the script's dependencies are met, it additionally waits until
> > all the scripts that depend on _it_ are ready to run. ("Just in time"
> > execution.) (The default is whenneeded=asap, "as soon as possible"
> > execution.)
>
> This mode seems to be specifically for [use case U.]
>
> This one seems uncommon, and less like a dependency use case than the
> others. How often is this wanted? Is it too inconvenient to just mark
> them all @whenneeded, and say something like:
>
> document.querySelector("#C").execute(function() {
> A.render();
> B.render();
> C.render();
> });
>
> That does require the modules render in a function, and not when the
> script is first executed. I don't know how much of a burden that is for
> this case.
If the scripts were able to expose an API like this, much of the work
we're doing here would be somewhat trivial. My impression is that we're
primarily talking about scripts from multiple third-party vendors that
aren't designed to interact together. There's an example in the use case
description, of a script that shows a video and a separate script that
shows slides synchronised with the video, where one inserts a <video> and
the other a <canvas>, and you want both to happen together so that you
never have one without the other.
(For a similar reason, I think it's probably not sufficient to just
provide JS modules as the solution to all these use cases. While modules
will certainly eventually become widespread, it will be many years before
all the libraries someone might want to use are in module form. The module
loader API allows authors to write scripts that work around this to some
extent, but that's probably above the skill level for many authors, who
just want to be able to include a script that was written by someone else,
and follow some copy/paste instructions for hooking the script up to the
relevant parts of their page.)
> Alternatively, if an event is fired when a script's dependencies have
> been met, then you could mark all three scripts @whenneeded, and call
> (#C).execute() once C's dependencies have been met.
I don't understand how this would work. Wouldn't this execute the
dependencies before C got loaded? The idea here is to download everything
first, then run it all at once.
> Will a @defer dependency effectively defer all scripts that depend on
> it?
I think, as proposed, it would. However, that's somewhat moot; if you have
a needs="" attribute you're going to be loaded async regardless.
On Fri, 30 Aug 2013, Ryosuke Niwa wrote:
> >
> > <script> gets a pair of methods, incDependencies() and
> > decDependencies(), that increase and decrease the dependency count by
> > one, respectively decDependencies() throws if called when the count is
> > zero. If decDependencies() is called and it reduces the number to
> > zero,
>
> I strongly oppose to adding incDependencies/decDependencies. We try not
> to add those pairwise functions as much as possible our C++ code because
> it's really hard to always pair function calls.
On Thu, 29 Aug 2013, Glenn Maynard wrote:
>
> incDependencies() and decDependencies() may be hard to debug, since if
> somebody messes up the counter, it's hard to tell whose fault it is. A
> named interface could help with this: script.addDependency("thing"); /*
> script.dependencies is now ["thing"] */
> script.removeDependency("thing");
That's better than a count, true. Jake Archibald suggested using promises
-- the API could accept a promise, and should then delay until all the
promises are resolved. Using promises like that is probably the easiest to
not screw up.
On Fri, 30 Aug 2013, Glenn Maynard wrote:
>
> I don't like the name "jit", because it already has a different meaning
> when talking about scripting. If this was for CSS or WebVTT or
> something else other than scripts, it wouldn't be as bad...
Seems reasonable.
On Tue, 3 Sep 2013, Ryosuke Niwa wrote:
>
> [...] in order for a dependency specified in "needs" to be satisfied,
> "src" content attribute of the dependent script needs to match the value
> when the script finished running. e.g. myscript.src = null leaves any
> dependency on myscript unsatisfied.
That seems reasonable. It would be a way to signal a load failure. I'm not
sure how compatible it would be with the ES6 loader though. Once you're
executing code, you're pretty locked-in in terms of what the dependencies
are. We could maybe just consider the dependency to have failed if a
script throws while being evaluated, though. That would match how it works
for new ES6 module scripts.
> Also make "needs" IDL property take in any HTML element; e.g. adding an
> image element to "needs" makes the script wait until the corresponding
> image resource is loaded.
Good idea. In fact, rather than passing just an element, it seems even
more powerful to be able to pass a promise, and to have elements that have
a pending load to have a .loaded attributes that returns a promise. This
would then integrate with Jake's idea of using promises to replace the
dependency API mentioned above. The only problem is that it cuts off the
UA from notifying the source of the promise that the resource is going to
be needed, in the cases where we're delaying resources until needed.
On Wed, 2 Oct 2013, Bruno Racineux wrote:
>
> I agree on the verbosity with the double markup. It feels redundant. But
> perhaps so is the repeat of the script name with 'needs="A.js"' for
> every script that would need a dependency.
Well, presumably we need _some_ markup to indicate what a script depends
on. I don't really know what else it would look like that would be less
verbose than just giving the URL. We _could_ put this information in the
script itself, as in modules, but then you have to fetch the file to know
which file to fetch next, which wouldn't address all the use cases.
> But if recompiling or looking up script+chars pairs are much slower than
> deserializing a compiled representation of an entire scripts, it might
> be worth considering down the road...
Well, again, nothing is stopping browsers from doing this today.
> >> I would also strongly favor restoring the previous spec portion of
> >> 'defer' which allow to have defer on inline script blocks (i.e. if
> >> the src attribute is not present).
>
> [...because] many inline functions have no need to run before
> 'interactive' fires. A delay or 'promise' at this stage is too early and
> rarely makes sense. Currently most common domReady hooks rely on
> DOMContentLoaded. As such I see no very good reason to run such plugin
> code prior to DOMContentLoaded.
>
> e.g I want to defer jQuery and I want my small inline script events
> (based on the context of a page) parsed and run post jQuery, right after
> DOMContentLoaded fires. That priority level is something that cannot be
> done right now.
Would it be sufficient to have the inline script depend on the jQuery
script using needs=""?
> Also something that makes me cringe, is the verbose repeat of long paths
> (just like srcset does)
Well we either have to repeat something, or do it from script.
I toyed above with using IDs or selectors, and it's at least as bad as
paths, IMHO. The main disadvantage of URLs is that it only lets us do
scripts. I discuss this more after the feedback, below.
>From script, there's basically two approaches that make sense, I think. We
could add dependencies using promises, and we could have some elements
expose an interface of sorts specifically for this purpose. The advantage
of the latter is that it would let the browser support "whenneeded"
semantics, loading images and style sheets only when a script needs them.
> If you need dependencies, then how about something shorter like a
> dependency Index, with a 'preload' semantic on top of the
> lazyload+postpone proposal, like:
>
> <script src="jquery.js" preload branch="A1">
> <script src="plugin1.js" preload branch="A2">
>
> <script src="plugin2.js" preload branch="A2">
>
> <script>
> E('plugin2.js');
> </script>
>
> i.e. The browser would takes the letter as indicator of a dependency
> tree branch, and follow along it's priority number to determine the
> dependencies to load when-needed. Or perhaps using the id attribute with
> the letter+number syntax form.
That seems rather convoluted. It's also hard to use this kind of scheme
when multiple authors are sharing a page without knowing about each other
(e.g. when you import two unrelated libraries).
> My worry with [the concept of 'dependency' attributes and relying or
> asking to the browser to handle it through markup], is a performance
> caveat and potential increasing bloat in pages, vs properly isolating
> what's needed on a per page basis. Platform like wordpress or drupal, or
> poorly written plugins in any platform, already too often add scripts
> globally to all pages, making pages an increasing piece of FUBAR script
> bloat. With the 'whenneeded' concept, it can become quite tempting to
> put many many scripts in the DOM without any guilt, or any sensible
> notion of wether it's actually needed or not for a particular page.
Fundamentally, any system that allows authors to load things on demand is
going to enable this kind of behaviour. I don't think we should let that
stop us from providing it. The cost of a few imports that don't get
fetched isn't going to have that substantial an effect.
On Thu, 29 Aug 2013, Brian Kardell wrote:
>
> "@slicknet: @Hixie @paul_irish this proposal conflates preloading with
> dependency management. I would ignore the latter (as I did originally)."
>
> "@paul_irish: @slicknet @Hixie I feel similarly. Adding HTML semantics
> for dep mgmt duplicates the work of AMD/CJS and ES6 modules.
> #writingemailishard :)"
>
> "@_JamesMGreene: @paul_irish @slicknet @Hixie Agreed, adding script
> dependency management in HTML would be complicated, messy, and verbose."
>
> Me: what they said.
Well, the idea is not to add something redundant with JS modules; the idea
is to very much integrate with JS modules. However, JS modules alone don't
solve many of the use cases described at the top of this e-mail. It's no
more complicated, messy, and verbose to have HTML support these use cases
natively than it would be to require that authors write scripts to support
them, IMHO (indeed I'd say it's a lot less messy). Do you think we should
just not support some of the use cases in the list above?
On Thu, 29 Aug 2013, Nicholas Zakas wrote:
>
> When Kyle and I originally started pushing for a way to preload
> JavaScript many moons ago, the intent was very simple: to allow the
> downloading of JavaScript and execution of JavaScript to be separate.
> The idea being that you should be able to preload scripts that you'll
> need later without incurring the cost of parsing and execution at that
> point in time. There are many examples of people doing this, the most
> famous being the Gmail mobile approach of loading JavaScript in comments
> and then pulling that code out and eval()ing it.
>
> I still feel very strongly that this pattern is a necessary evolution of
> how we should be able to load scripts into web pages. I just want a flag
> that says "don't execute this now" and a method to say "okay, execute
> this now". Allowing that flag to be set both in HTML and JavaScript is
> ideal.
This is what "whenneeded" and "execute()" provide, in the proposal from
earlier in this thread.
> The question of dependency management is, in my mind, a separate issue
> and one that doesn't belong in this layer of the web platform. HTML
> isn't the right spot for a dependency tree to be defined for scripts (or
> anything else). To me, that is a problem to be solved within the
> ECMAScript world much the way CSS has @import available from within CSS
> code.
What about dependencies on resources that aren't scripts?
> I think the use cases other than the initial one (preload/execute later)
> are best relegated to script loaders and are very tied to a current way
> of thinking about loading JavaScript.
Surely our goal should be to make script loaders unnecessary.
> I'd rather provide a simple, low-level piece of functionality that make
> the job of script loaders easier by providing a reliable API and then
> let the dependency management use cases be addressed outside of HTML.
Can you elaborate on why?
It seems like having the browser be able to manage the dependencies across
scripts and other resources, and manage the loading of those resources,
would let the browser much better manage the network. There's no way for
an author-provided script loader or other resource manager to know when
other tabs are done loading critical resources so that non-critical
resources can be preloaded, for example.
> Other random thoughts:
>
> * "whenneeded" is a very strange name for that attribute. It doesn't
> really tell me anything, as opposed to "preload", "noexecute", or
> "future". How do I know when it will be needed?
Yeah, whenneeded="" is a poor name. What we really need is a way to give
the element's load policy -- should it precache or not, should it load
asap or be deferred... For some elements, like scripts or style sheets, we
might also want to provide the author control over whether the element
should block subsequent scripts or be asynchronously loaded and applied.
On Thu, 29 Aug 2013, Ryosuke Niwa wrote:
>
> To put it another way, I don't see why anyone wants to load a script and
> not execute it other than for the purpose of avoiding the network
> request at a later time. However, if that were the main purpose of
> providing such a functionality, then we also need to address the issue
> of this load request needing to have a lower priority than other load
> requests that are vital for the page. In fact, we might want to avoid
> sending the request of a script file altogether if the user isn't going
> to interact the parts of the page that needs such a script.
Right. That's what many of the use cases described above are about, which
is how a dependency scheme ended up being part of the proposal in the
first place.
On Wed, 4 Sep 2013, William Chan (陈智昌) wrote:
>
> * <link rel=subresource> is great for resource discovery. Given the
> above observation, note that it has some deficiencies. Most obviously,
> it does not indicate the resource type. Browsers today can heuristically
> assign a priority based on the resource type (script/image/stylesheet/
> etc). Arguably, browsers could just use the filename extension as a hint
> to the resource type, and that'd get us most of the way there. In any
> case, Chromium, when it encounters <link rel=subresource> is going to
> assign the resource load the lowest priority level, and only when the
> parser encounters the actual resource via a <script> tag or something,
> will another resource load be issued with the "appropriate" priority.
> Almost all modern browsers will hold back low priority resource loads
> before first paint in order to get critical scripts and stylesheets in
> <head> ASAP without contention. Anything marked with <link
> rel=subresource> will be considered low priority and in all likelihood
> not requested early. Note that HTTP/2 currently does not support
> re-prioritization (and that feature is being debated), so that means
> that when the resource load for <link rel=subresource> gets issued over
> an HTTP/2 connection, it will have the lowest priority, which is
> probably undesirable. FWIW, I think <link rel=subresource> was a good
> initial start, but suffers from key weaknesses and should be thrown out
> and replaced.
It seems pretty clear that in general it's better to provide the resource
using its proper form -- be that <img>, <link rel=stylesheet>, <link
rel=icon>, <script>, whatever -- and annotate it with attributes saying
how to load it -- asap, later, when needed, whatever -- than it is to just
generically say "also, I might eventually perchance refer to this URL".
The former would allow the browser to also preparse the contents, e.g.
decoding an image, parsing a style sheet or script, preparsing an HTML
file, and the like.
> * Given current browser heuristics for resource prioritization based on
> resource type, all <script> resources will have the same priority.
> Within HTTP/1.X, that means you'll get some amount of parallelization
> based on the connection per host limit and what origins the script
> resources are hosted, and then get FIFO. New additions like lazyload
> attributes (and perhaps leveraging the defer attribute) may affect this.
> With HTTP/2, there is a very high (effectively infinite) parallelization
> limit. With prioritization, there's no contention across priority
> levels. But since script resources today generally all have the same
> priority, they will all contend and most naive servers are going to
> round robin the response bytes, which is the worst thing you could do
> with script resources, since current JS VMs do not incrementally process
> script resources, but process them as a whole. So round-robining all the
> response bytes will just push out start time of JS processing for all
> scripts, which is rather terrible.
I'm not sure what to do about this exactly.
> * Obviously, given what I've said above, some level of hinting of
> prioritization/dependency amongst scripts/resources within the web
> platform would be useful to the networking layer since the networking
> layer can much more effectively prioritize resources and thus mitigate
> network contention. If finer grained priority/dependency information
> isn't provided in the web platform, my browser's networking stack is
> likely going to have to, even with HTTP/2, do HTTP/1.X style contention
> mitigation by restricting parallelization within a priority level. Which
> is a shame since web developers probably think that with HTTP/2, they
> can have as many fine grained resources as they want.
It's hard to come up with a super fine-grained model that works well with
multiple competing scripts, but we can do better than what we have now,
certainly. It seems we can at least split things into the following
categories, in order of highest priority to lowest:
1. resources that are needed and are causing something to block
e.g. <script src="foo.js"></script>
2. resources that are needed and are neither blocking anything nor
explicitly deferred
e.g. <img src="foo.png" ...>
3. resources that are needed but are deferred
e.g. <script src="foo.js defer></script>
4. resources that the browser wants
e.g. <link rel=icon>, <html manifest>
5. resources that are not yet needed but which the author wants
precached when possible, and which have not been marked deferred
e.g. <link rel=subresource href=...>
6. other resources
Is that fine-grained enough?
We could add other levels too. Maybe a "defer" variant of #5, for
instance:
<script src="foo.js" whenneeded precache defer></script>
...or some such. Or maybe put these things in a "load policy" attribute,
as mentioned above.
On Tue, 3 Sep 2013, Ryosuke Niwa wrote:
>
> Use case: A web page wants to load and execute a script widget.js if the
> script is already cached in the browser. However, it wants to load
> other essential assets such as images first if it's not already in the
> cache except as long as the user had not started interacting with the
> parts of the page that require widget.js.
>
> i.e. it (loads and) executes the script immediately when and only when
> the script had already been cached or the user had started interacting
> with the parts of the page that requires the script. Otherwise, the
> script is loaded with a low priority.
(I've added this one to the list above as use-case L.)
This seems reasonable. It's kind of opportunistic loading -- it's saying
execute this ASAP, but load it when needed, albeit with precaching if
that is necessary.
On Thu, 23 Jan 2014, Bruno Racineux wrote:
>
> What bugs me the most is that a developer's expectations is superseded
> by a feature (the preloader) with different implementation per browser
> engine, that are neither documented (in plain English) nor specced out
> by W3C or WHATWG standards.
Well the spec is just "parse the document and fetch the URLs you find",
basically. It's a reasonably simple model. The implementation is a bit
more subtle due to off-the-main-thread parsing, document.write(), and so
on, but that shouldn't affect authors all that much.
> The lack of such resource control can be a huge waste of bandwidth in
> collateral damage along the benefits of the pre-loader. And in the case
> of responsive images, it prevents us from implementing any simple
> straight forward js solutions.
I don't know about "straight-forward", but it shouldn't stop you from
making scripted solutions in general. What you can't do from JS is poke
content into the preloader before the script runs, which is what the
preloader is basically for. (This is why the proposal earlier in this
thread includes a dependency model: it lets you provide that information
to the browser before script actually runs, so that the browser can do
useful things with the information it has earlier.)
> Anyway, to come to the point of this new parallel thread, this leads me to
> a suggestion:
>
> 'HIDDEN' as [resources control]:
>
> Could 'resource control' be an associated spec of the 'hidden' attribute?
> The semantics seem compatible with the specs implied by 'hidden'?
>
> Being that: hidden "Specifies that the element represents an element that
> is not yet, or is no longer, relevant" [1]. That suggest it may not be
> needed at all and if so, why load it's associated resources?
It would certainly make sense for a browser to defer such a load. I don't
know that it would make sense to not load it at all, though. However, it
would make sense to provide controls for that.
On Fri, 24 Jan 2014, David Newton wrote:
>
> In addition to overloading `hidden`, it misses the `postpone` use case
> of images that we want to be visible (i.e. not have a `hidden`
> attribute), but not loaded until/unless the user scrolls enough for them
> to be within the viewport.
Yeah. One thing we could do to make that work would be to have images do
something similar to "whenneeded", where instead of an execute() method to
indicate that they are needed, they trigger that state when the browser
would otherwise try to render them.
On Sun, 26 Jan 2014, Qebui Nehebkau wrote:
>
> Basically, - and I'm trying not to over-elaborate here, since my opinion
> isn't really very important - I just mean that I don't think there
> should be any guarantees about how (or whether) browsers will preload,
> nor any specific means of controlling this, because the way resources
> get loaded is not really any of the author's business. I also think that
> the purely presentational choice of a specific image file to represent
> the same content (and, even in the art direction case, they're clearly
> the same content if they can be represented with the same alt text;
> otherwise, there should be multiple img tags) should be specified in
> CSS, not HTML; the argument that preloaders can't consider CSS isn't
> compelling to me, because a browser's choice to preload an image or not
> isn't important enough (or, I think it shouldn't be) to justify
> entrenching in a specification.
I think this makes sense, insofar as the UA should have the final say (not
the author) regarding how things are downloaded. But on the other hand,
the UA can do a better job if the author is able to provide hints to the
UA about what the best order might be.
On Wed, 12 Mar 2014, Jake Archibald wrote:
>
> One of the problems with async scripting is doing something when/if it's
> ready. A complete solution looks like this
> https://gist.github.com/jakearchibald/7662e012462c7537a075, it would be
> a lot easier if we could just do:
>
> thing.loaded().then(function() {
> console.log('loaded');
> }, function() {
> console.log('failed');
> });
Yeah, it would make sense for objects that have an eventual "ready" state
to have an attribute that returns a promise for the current load state.
That would fit in well with the model of adding dependencies by handing a
promise over.
On Wed, 12 Mar 2014, Boris Zbarsky wrote:
> On 3/12/14 7:23 AM, Jake Archibald wrote:
> >
> > If the element hasn't loaded or is loading, vend a promise that
> > resolves/rejects on its load/error event. If the element has fired
> > load/error and isn't loading due to a source change, vend a
> > resolved/rejected promise.
>
> This seems fundamentally racy, no?
If you're changing what your image is pointing to, then yeah. We could
vend an ImageBitmap object on the promise, I guess, if that's likely to be
a problem. But in practice I don't see why it would be. Who's going to be
using the same image to load multiple images without waiting for one to be
ready?
On Wed, 12 Mar 2014, Boris Zbarsky wrote:
>
> I realize no one would write actual code like this; the real-life use case I'm
> worried about would be more like this:
>
> // img is already loaded sometimes
> // Would like to observe a new load
> var promise1 = img.loaded(); // oops! This will be pre-resolved if
> // we were already loaded, but otherwise
> // will resolve with the new load we're
> // about to start.
> img.src = bar;
promise1 would be rejected as soon as you set 'src' if it hadn't loaded
yet. If it had loaded, it would resolve straight away. In the latter case,
you might observe either the old image or the new one, there's no way to
know for sure.
This is certainly bug-prone and I'm sure people will get it wrong and
it'll usually work but sometimes not, due to the race. However, it's a
logic error -- you're always observing the first load, not the second. It
will always resolve straight away, either aborting or succeeding based on
whether the original load is aborted or had completed.
On Wed, 12 Mar 2014, Domenic Denicola wrote:
>
> With promises you should only ask for the "loaded" promise *after*
> setting `src`; anything you retrieve before that represents a previous
> load. Except, I suppose, for the base-case of images with no src,
> transitioning to having an src? Or are they considered to have e.g.
> loaded `about:blank` already? I.e. what should this do?
>
> var img = document.createElement("img");
> var promise1 = img.loaded();
> img.src = "foo.png";
> var promise2 = img.loaded();
I think we should spec this case to reject promise1, since the image is
not .complete. I definitely don't think we should say that promise1 waits
for the src to be set.
> // (4) or it could be rejected with an "InvalidStateError" saying you
> // can't wait for the loading of a non-src'ed image.
This would be a perfect case for a sync exception, rather than a rejected
promise, IMHO. Throwing an exception synchronously would clearly indicate
to the programmer that the code is Just Wrong.
On Fri, 14 Mar 2014, Jake Archibald wrote:
>
> Problem: Initialising an app after a non-module script
> Solution: https://gist.github.com/jakearchibald/000ab94ad9fa5cfe62a8
This seems simpler:
<script src="/whatever.js" id=whatever async></script>
<script type=module needs="whatever">
import app from "myapp";
app.init()
</script>
We would have to make sure, though, that needs="" blocked the execution of
the script _after_ the script was parsed to pull out 'import' statements.
> [Use-case Q:] Want to avoid executing a social-media script until the user
> give some intent, although the script should be preloaded.
> Solution: https://gist.github.com/jakearchibald/dd25f0f2cf47bf2ab93e
This seems simpler:
<script id="socializor" src="http://myface.com/socializor.js" whenneeded></script>
<script>
document.ready.then(function () {
document.querySelector('.social-button').addEventListener('click', function(event) {
document.scripts.socializor.execute();
event.preventDefault();
});
});
</script>
> [Use-case S:] One plugin wants to execute "A.js" and "B.js" in order
> following an interaction. Another wants to load "A.js" then "C.js" & "D.js"
> in either order. "A.js" should only execute once. Scripts aren't written as
> modules and out of developer's control.
> Solution: https://gist.github.com/jakearchibald/120309d88a8bf025e92e
That's a lot longer than the original proposal's solution. Also it
requires the plugins to know about each other. Also it uses markup. If we
can use markup, then the solution becomes even simpler than the original
proposal's solution, IMHO:
<script src="A.js" whenneeded></script>
<script id=B src="B.js" whenneeded needs="A.js"></script>
<script id=C src="C.js" whenneeded needs="A.js"></script>
<script id=D src="D.js" whenneeded needs="A.js"></script>
// CMS plugin 1
<script>
document.querySelector('.button').onclick = function(event) {
document.scripts.B.execute();
}
</script>
// CMS plugin 2
<script>
document.scripts.C.execute();
document.scripts.D.execute();
</script>
This is dramatically simpler than the solution presented above.
> [Use-case T:] Preload 2 scripts, execute one or the other on particular
> interactions
> Solution: Same as Q.
Similar to Q, I guess, but presumably not identical. Q only has one
script. Again, though, I don't really see why we'd want something as
complicated as suggested in that gist, when we can just have two script
elements and call "execute()" on the one we want.
(I note here that actually my solutions to Q and T here and in my e-mail
from last year actually make the mistake of not distinguishing scripts
that should be preloaded from those that should not. We probably need an
explicit way to control the load policy here, as mentioned earlier in
this e-mail.)
> [Use-case U:] "A.js", "B.js", "C.js" - load them in parallel, execute in
> order, only execute when all have preloaded.
> Solution: https://gist.github.com/jakearchibald/5898e3a4fce62579d75b
At a glance I've no idea what this script is doing. I don't think we want
to be requiring that authors follow this kind of convoluted code to do
something as simple as use case U. Recall that with the whenneeded=jit
proposal and with needs="" taking URLs, this was as simple as:
<script src="/a.js" whenneeded=jit></script>
<script src="/b.js" whenneeded=jit needs="/a.js"></script>
<script id=c src="/c.js" whenneeded=jit needs="/b.js"></script>
<script>
// when we need it...
document.scripts.c.execute();
</script>
> [Use-case V:] As U, but don't need to wait for all before executing.
> Stop executing if any script fails to load.
> Solution: https://gist.github.com/jakearchibald/ea7583d50bf3b46395e0
It's not at all clear to me how a random author is supposed to figure out
the difference between your solution to U and to V. It seems like any
solution we provide for this should be way more straight-forward.
The solution using the "whenneeded" proposal is the same as for U but with
the "=jit" bit removed. I think we should probably make this more clear,
e.g. making it policy="precache late-execute" vs policy="precache
early-execute" or some such, but that's a far cry from going all the way
to requiring that authors reduce arrays of promises.
(Though to be fair, the solution I proposed to V doesn't actually go as
far as the use case asks for, since it doesn't abort later loads. I think
I intended tho onerror function in that solution to manually go in and
stop the loads, but I'm not sure what exactly one could do to do that,
since they're trying to preload, at least. Maybe we should just require
that UAs be clever enough to notice that if they have aborted execution of
a particular dependency chain, they should abort the loads too if they
have no reason to think the loads will be useful later.)
> [Use-case W:] As W, but break on execution errors
> Solution: https://gist.github.com/jakearchibald/1b12a0e5414a69d9350f
That's WAY more complicated than the whenneeded="" proposed solution.
> [Use-case X:] Loading non-js dependencies
> Solution: Use XHR + preload for prescanner
XHR makes it hard to hook into the prioritisation system, but yeah.
> [Use-case Y:] Some libraries may need async initialization.
> Solution: These libs should provide a ready promise.
Agreed, though I would just have them hand that promise to the <script>
element so that it hooks into the rest of the dependency system.
> [Use-case Z:] Wait on existence of particular element before executing
> script
> Solution: Either put the <script> that handles script loading after the
> element in question, or use mutation observers
Yeah.
On Sat, 15 Mar 2014, Jake Archibald wrote:
>
> It's everything we need but perhaps not everything we desire. Last time
> we went round with script loading the proposal for high-level dependency
> declaration got weighed down by use-cases that should have been left to
> lower level primitives. These are the lower level bits, something higher
> level is still possible.
It's not clear to me that promises really are the right "low-level" bits
here. I think we need something lower than those that lets the JS module
system, the HTML Imports system, the <script needs> system, and any
promise-based dependency system all interact in one coherent way.
> For legacy-free project, modules + promises for non-script assets are
> the answer.
How do modules solve the problems discussed here of defining when things
should preload, wait til they're needed, etc?
On Fri, 14 Mar 2014, Kyle Simpson wrote:
>
> I'd also like to make the observation that putting <link
> rel=preload>.loaded() together with <script>.loaded(), and indeed
> needing a promise mechanism to wire it altogether, is a fair bit more
> complicated than the initial proposals for script preloading use-cases
> from the earlier threads over the last few years of this list.
>
> For one, we're talking about twice as many DOM elements. For another,
> there's a seemingly implicit requirement that we have to get both ES6
> promises and DOM promises to land for these suggested approaches to
> work. I don't know if that's already a guarantee or if there are some
> browsers which are possibly going to land DOM promises before ES6
> promises? If so, ES6 promises become the long pole, which isn't ideal.
>
> Lastly, I'd observe that many of the arguments against the
> original/previous script preloading proposals were heavily weighted
> towards "we don't like script loaders, we want to make them obsolete, we
> need simple enough (declarative markup) mechanisms for that stuff so as
> to make script loaders pointless…"
>
> At one point the conversation shifted towards ServiceWorker as being
> "the answer". When we explored the use cases, it was my impression there
> was still a fair amount of non-trivial code logic to perform these
> different loading cases with SW, which means for the general user to
> take advantage of such use-cases, they're almost certainly going to need
> some library to do it.
>
> I can't imagine most end-users writing the previously-suggested
> ServiceWorker code, and I'm having a hard time believing that they'd
> alternatively be writing this newly suggested promises-based loading
> logic all over their pages. In either case, I think for many of the
> use-cases to be handled, most general users will need to use some
> script-loader lib.
>
> So, if this .loaded() DOM promises thing isn't the silver bullet that
> gets us to "no script loader utopia", then I don't see why it's
> demonstrably better than the simpler earlier proposals.
>
> Moreover, the earlier proposals relied on the browser having logic
> built-in to handle stuff like "download in parallel, execute serially",
> which made their interface (the surface area users needed to work with)
> much less than either the Promises here or the ServiceWorker before.
>
> What you're implicitly suggesting with both sets of suggestions is,
> let's make the user do the more complicated logic to wire things
> together, instead of the browser doing it. Why?
>
> Why isn't putting preloading into existing <script> elements (whether
> exposed by events or by promises) better than splitting it out into a
> separate element (<link rel=preload>) and requiring a third mechanism
> (promises) to wire them up?
I have to agree with Kyle here.
On Sat, 15 Mar 2014, Jake Archibald wrote:
>
> Yep, markup is important for preparsers. <module>/<script type="module">
> & ES6 modules give us a solution for the future.
I don't really understand how. Modules offer one small part of what we're
talking about here, but not much more. They don't offer a way to declare
the dependency tree before the files are fetched, there's not really a way
to concatenate modules without putting them in some other file like a ZIP
file or an HTML Import, there's no way to delay the load or execution of a
module until it's needed as far as I can tell, there's no way for modules
to be declared as dependent on other resources, etc. I think modules will
be an important part of this solution, but I don't think they are, on
their own, a complete solution to the use cases presented.
Certainly without a lot of rather complicated code.
On Tue, 22 Jul 2014, Ben Maurer wrote:
> On Tue, Jul 22, 2014 at 10:26 AM, Ian Hickson <ian@hixie.ch> wrote:
> > On Mon, 21 Jul 2014, Ben Maurer wrote:
> > >
> > > (1) Allowing the user to specify parameters to Fetch. For example, a
> > > user could say:
> > >
> > > <script src="/my.js" params="{'headers':{'myheader':'value'}}"
> > > id="myscript" />
> > >
> > > This would allow the user to make any type of request customization
> > > that they could for a direct call to Fetch.
> >
> > I think this would make a lot of sense. It's similar to earlier
> > suggestions for controlling "Referer" on a per-link basis, but more
> > generic. The problem I had with the proposals for controlling Referer
> > was that while there's an obvious way to do it for <script> and
> > <link>, it quickly starts breaking down don't have a 1:1 mapping of
> > URL to element. For example, how do you get the fetches of URLs in a
> > style sheet? Or of the poster frame of a <video> element? Or
> > EventSource objects? Should we just have different ways to set the
> > options for each one?
>
> I guess the upshot of of doing this through fetch is that once we added
> the ability to specify fetch metadata it would hopefully reduce the need
> for future modification of all the different ways one could load an
> object.
> http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0129.html
> suggests the idea of using fetch for stylesheet subresources in the
> context of subresource integrity.
Yeah. I think it makes sense to expose a Request object once one is
underway, and a RequestInit object (probably in the form of a JSON-encoded
content attribute?) to configure it, at least for the main resources.
I'm not sure how to handle elements with multiple resources, e.g. <video
poster> or the new <picture> stuff.
> > > (3) Allowing the user to construct a script or stylesheet from a
> > > fetch. Complex sites often want precise control over when scripts
> > > and stylesheets are loaded and inserted into the DOM. For example,
> > > today inserting a stylesheet blocks the execution of inline script
> > > tags. Some sites may know that this dependency is not needed.
> >
> > This specific use case is something I'm already working on. My
> > long-term plan is to integrate something like this with the HTML
> > Imports dependency model and the ES Module dependency model so that we
> > have a single model that can handle everything.
>
> This sounds interesting. The way we render pages at Facebook seems very
> similar to what you are suggesting. We essentially flush sections of
> HTML with a list of CSS and JS dependencies for each section. The HTML
> is only rendered once these resources are loaded. In essence, it seems
> like we're doing inline HTML imports. We have a few other use cases for
> this type of dependency (for example, we have a method where you can say
> "call this callback once resources X, Y and Z are requested".
Presumably the callback part of this could be done using promises if we
expose promises for everything that can load.
(I've added the above, as well as some other use cases you listed, into
the use case list at the top of this e-mail, as use cases I through K.)
> > > var myfetch = window.fetch(...);
> > > myfetch.then(function(resp) {
> > > document.body.appendChild(resp.body.asStyleSheet());
> > > });
> > >
> > > By calling asStyleSheet, the user could preserve the devtools
> > > experience that exists today while still having complete control
> > > over the fetching of their content.
> >
> > We could do this too. It's mostly just a convenience method, right?
>
> One advantage of doing this is that if there is some use case a site has
> that isn't met by the dependency model they can still manually separate
> the fetch of an object from its insertion into the DOM. Giving the
> author the freedom to manually separate the fetch of a resource from
> it's use in the document gives them a powerful ability to experiment
> with different approaches to resource loading. asStyleSheet/asScript
> wouldn't merely be a helper method to construct a stylesheet from a
> given string of text. For example, line numbers in developer tools (or
> JS stack traces) as if they were loaded directly from the given URL. A
> browser might decide to parse the JS/CSS in a background thread as soon
> as the document was fetched (or cache a pre-parsed version of the file).
If we provide a way to not apply the resource until it's "needed", doesn't
that just take care of the above automatically? I'm not sure I understand
precisely the use case here.
> This model also might be beneficial for sites that were written prior to
> the dependency model you are describing. For example, at Facebook we
> already schedule JS/CSS loading ourselves. This API would allow us to do
> things like fetch a CSS stylesheet without blocking inline script
> execution that follows while making a minimal number of changes to the
> site.
Can't you do that already? I'm not really following what you need to do
here that you can't already do.
On Tue, 22 Jul 2014, Boris Zbarsky wrote:
>
> One issue worth considering here: there are various situations (CSP,
> extension) in which a browser would like to know what sort of resource
> is being loaded, or more precisely how it will be consumed, before
> loading it.
This argues strongly for either reusing the existing loading mechanisms
for preloading, or at least for providing that context information in the
preload request.
On Tue, 22 Jul 2014, Ben Maurer wrote:
>
> To follow this up with a concrete suggestion:
>
> var myfetch = window.fetch('my.css', {'fetch-as': 'stylesheet'});
> myfetch.then(function(resp) {
> document.body.appendChild(resp.body.asStyleSheet());
> });
>
> You can only call asStyleShet if fetch-as=stylesheet. Passing this
> parameter would cause the browser to do all the things it would do if it
> were fetching a stylesheet. For example, it would specify an accept
> header of text/css unless otherwise specified. It would request at the
> same priority as the browser requests other stylesheets (again, unless
> overridden with a yet-to-be-defined syntax). Rules around CORS and
> tainting would be identical to a normal stylesheet fetch (namely that
> you could call.asStyleSheet on a request to a different origin but it
> would have whatever restrictions the browser has on stylesheets from
> different origins). Links in the stylesheet would be interpreted
> relative to the URL used to load it, etc.
>
> Essentially, fetch-as=stylesheet would be the canonical definition of
> the browser's behavior around loading stylesheets. It would define the
> behavior if the proposals I suggested in the original email were
> implemented -- namely if the user chose to pass parameters to the fetch
> algorithm or if the user accessed the result of a stylesheet's fetch.
>
> Boris, Will -- would this setup address the concerns you have about the
> problems websites that use XHR to load resources encounter?
How would this interact with th ES6 module loader? Would fetch() be above
or below it?
On Wed, 30 Jul 2014, Ben Maurer wrote:
> On Wed, Jul 30, 2014 at 11:35 AM, Ian Hickson <ian@hixie.ch> wrote:
> > On Wed, 30 Jul 2014, Anne van Kesteren wrote:
> > >
> > > it would be desirable to have Accept / Accept-Language be set by
> > > APIs, such as <img>. XMLHttpRequest already does this (unless a
> > > developer added those headers), see http://xhr.spec.whatwg.org/
> > >
> > > If we are eventually going to expose something like a "Fetch" object
> > > for each API that can issue a fetch it would seem best if these
> > > details were defined at the API-level.
> > >
> > > I guess for now I'll add some notes to the network-level bits of
> > > Fetch to indicate Accept / Accept-Language cannot be set at that
> > > point by the user agent.
> >
> > There's three ways that I see:
> >
> > 1. Expose it on a "fetch" object available from all the places that can
> > do fetches. (HTMLImageElement, XMLHttpRequest, StyleSheet, etc)
> >
> > var img = new Image();
> > img.src = 'foo.png';
> > img.fetch.doWhateverWithTheAcceptHeader('foo');
>
> At what point is the fetch actually being initiated? It's possible that
> fetch will offer some things which can be done post-request (eg,
> dynamically changing the spdy priority), but the accept header may need
> to be specified pre-request.
The fetch wouldn't be initiated until the event loop spun, but other than
that, it's hard to predict exactly when it'll be done in the general
sense. Depends on things like the load policy.
On Thu, 31 Jul 2014, Anne van Kesteren wrote:
>
> Probably not before the end of the current task. The only exception to
> that is EventSource and maybe WebSocket, but they can have a constructor
> argument of sorts to make this work I guess.
WebSocket probably won't use fetch. Good point about EventSource though.
If we want to add requestInit settings for that, please file a bug.
On Thu, 7 Aug 2014, Ilya Grigorik wrote:
>
> Latest draft: https://igrigorik.github.io/resource-hints/
The preconnect, preload, and prerender link types seem important to define
in more detail, I'm glad you are doing this work. I suggest that for
things like scheduling and prioritisation, we reuse the proposals that
this thread end up at (whatever that is, be in the proposal below or
something evolved from that).
Are there requiirements and use cases that you need to address that aren't
covered by the proposals in this e-mail? I think I covered them all, but
I'm not 100% sure.
On Fri, 8 Aug 2014, bizzbyster@gmail.com wrote:
>
> +1 to breaking the dependency between fetching the resource and how it
> is later used in the document. This type of “late binding” enables many
> page optimizations.
Does anyone have a concrete depiction of this use case so we can evaluate
the proposal in this thread againt the use case?
On Mon, 11 Aug 2014, Ilya Grigorik wrote:
>
> Will this result in API that extends beyond import and ES6 module use
> cases? For example, I want to have the building blocks that will allow
> me to declare these dependencies on my own: "these two images before
> that script, but after this stylesheet, oh and that stylesheet should
> have higher priority than"... We can express all of this in HTTP/2, and
> I'd like that to be surfaced to the developers as a first class API.
That's my goal. I don't know if the ES modules spec will be extended
sufficiently to support that, but I hope so. The alternative is that we
have two mostly redundant dependency systems, which I assume wouldn't be
popular with browser vendors.
> I'm looking at the gliffy, but having a hard time understanding how this
> will work... It's murky to me how I'd declare a resource, specify its
> priority relative to others, and/or add a dependency. Any other (more
> complete) examples, by any chance? :)
Check out the examples at the bottom of this e-mail, let me know if they
answer your question, let me know how they look!
That concludes the feedback that was sent on the previous proposals.
There's also some other developments that are relevant.
There's JavaScript's modules, as mentioned earlier. Modules introduce
their own dependency system. It would probably behoove us to integrate
them with whatever we have for making scripts depend on images and so on.
HTML Imports are also coming along, and they also have a dependency
system. Again, we should probably make sure that this integrates with the
JavaScript modules dependenc system and whatever we come up with to
address the use cases listed earlier.
There's a bug tracking the merging of the dependency systems:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25715
I also brought this up in es-discuss recently, in a series of e-mails on
the subject.
Before we can come up with a coherent overarching model, though, we need
to know what precisely it is we need to address the use cases in this
e-mail. Let's first look at the dependency tree aspect.
There's a variety of objects that one might want to depend on:
- JS modules
- <script> elements
- <img> elements
- <video> elements
- promises
- inline style sheets
- external style sheets
- HTML imports
- etc
Some can be identified by ID, some by URL, some by element or object,
others by some sort of name.
They don't all need to be identifiable from an attribute. For example, I
don't think we need to make it possible for a <script> to depend on a
promise declaratively. It's ok if depending on a promise can only be done
via an API call.
Some of these are somewhat special. For example, if we want multiple
<scripts> pointing to the same src="" to be deduped, then the dependency
mechanism needs to be based on URLs in some way (and presumably
pre-redirect URLs otherwise we make the dependency mechanism depend on
network latency). HTML imports also probably have to be URL-based, because
the actual Document object that an HTML import imports doesn't exist until
the import has been started.
Modules make this a little more complicated, in that there's a desire that
modules be named so that you can e.g. import "jquery" and be safe in the
knowledge that jQuery will be imported regardless of its local filename,
assuming that it has been previously declared.
In HTML imports, the mechanism to identify another HTML import to depend
on is <link rel=import href="...">. This only gets invoked once the
resource has already been fetched. HTML imports are identified by URL.
That URL has to be deduped -- each master document only imports each
URL once.
In JS modules, there's syntax in the script itself, which works similarly.
The syntax identifies modules using a string. The script is first parsed,
the dependencies are identified, they are fetched, this happens
recursively, and then the scripts are evaluated.
CSS similarly has @imports, though those are currently _not_ deduped. We
should probably change that, so that at least CSSRuleLists are deduped.
Alternatively, we can have a feature that forces deduping (or vice versa).
To avoid the latency of a round-trip per dependency level, it would be
good if the dependencies could be predeclared, even for e.g. CSS or JS
modules, where you would normally only mention the dependency when you
import it.
Some dependencies have a presence in the same document, or can have a
presence without any particular difficulty. For example, <script src="">
elements (not modules) all get listed in the document, even if they depend
on each other. However, not all dependencies are this way. For example,
ES6 modules can reference modules that aren't otherwise mentioned.
Similarly, style sheets can @import other sheets, but if you <link
rel=stylesheet> those sheets in the parent document, you're going to
change the cascade in probably noticeable (page-breaking) ways.
So if we have a way to declare dependencies declaratively in the markup,
we have an interesting mixture of requirements, even if we assume that
we're not going to be able to reference things like promises declaratively
and can safely leave those to an API:
- being able to reference specific elements (e.g. depending on an inline
script or style block)
- being able to reference specific URLs in the context of specific
handling (e.g. "this URL is an ES6 module that someone will import", or
"this URL is a CSS file that someone will try to @import")
This suggests either that the dependency mechanism needs to be able to
take different types of identifiers (e.g. element IDs or selectors on the
one hand, and URLs+contexts on the other), or that we need to have two
ways to declarare dependencies, e.g. two attributes (one for IDs, one
for URLs+contexts), or that we should rely on rel=preload/rel=subresource
to handle the second type.
Here's how these three options could look, assuming that bar.css is a CSS
file that foo.css imports, and "baz" is the ID of an element that this
style sheet depends on (maybe a <script> element).
* different ways we could jam all this into one attribute:
<link rel=stylesheet href="foo.css" dependson="bar.css as css, baz">
<link rel=stylesheet href="foo.css" dependson="css:bar.css baz">
<link rel=stylesheet href="foo.css" dependson="bar.css css; #baz">
* different ways we could have multiple attributes to split this
information out into:
<link rel=stylesheet href="foo.css"
dependson-id="baz" dependson-css="bar.css">
<link rel=stylesheet href="foo.css"
dependson="baz" dependson-href="bar.css as css">
* using just IDs and rel=preload or rel=subresource:
<link rel=subresource type="text/css" href="bar.css" id="bar">
<link rel=stylesheet href="foo.css" dependson="bar baz">
<link rel=preload type="text/css" href="bar.css" id="bar">
<link rel=stylesheet href="foo.css" dependson="bar baz">
<link rel="preload stylesheet" href="bar.css" id="bar">
<link rel=stylesheet href="foo.css" dependson="bar baz">
* reusing the existing mechanisms for each type, but having a way to force
a particular case not to be instantiated ever, because it will instead
be instantiated using the other mechanisms (e.g. @import):
<link declare rel=stylesheet href="bar.css" id="bar">
<link rel=stylesheet href="foo.css" dependson="bar baz">
These all suffer from pretty notable disadvantages: complicated syntaxes
in attributes or complicated multiple-attribute processing models for the
first five cases, having to introduce a whole new way to declare that
something is "CSS" for all but the last two, and lack of a decent
backwards- compatibility story for the last two. The three before the last
one also suffer from not having an obvious way to be extended to
predeclare JS modules. The last one could be extended easily enough:
<script declare type=module id=jquery href="p/jq/main.js"></script>
<script type=module dependson=jquery>
import $ from "jquery";
</script>
We could also introduce a new void element specifically for preloading:
<preload kind=stylesheet href="bar.css" id="bar">
<link rel=stylesheet href="foo.css" dependson="bar baz">
...where the "kind" is from a list of predefined types that browsers can
preload, like "stylesheet", "module", "script", "image", etc. However,
introducing a new void element is a non-trivial cost.
Two other problems with the <link> examples above are the duplication of
information because of using id="", and the use of type="", a MIME type,
to identify the resource type, when in practice how to handle a feature
depends on both more than the MIME type (e.g. script program vs ES6
module) and less than the MIME type (e.g. most image/* types are handled
by sniffing, not based on the type). The declare="" idea avoid this by
reusing the existing mechanisms.
Merging the <preload> and rel=preload/rel=subresource ideas, one could
imagine a variant that used a different attribute rather than type=, so
that we didn't have to give a MIME type.
<link rel=preload as=stylesheet href="bar.css" id="bar">
<link rel=stylesheet href="foo.css" dependson="bar baz">
...or:
<link rel=subresource kind=stylesheet href="bar.css" id="bar">
<link rel=stylesheet href="foo.css" dependson="bar baz">
rel=subresource has the minor advantage of being already implemented in
Chrome, at least. On the other hand, rel=preload is shorter and would let
us use a shorter attribute name (as="" vs kind="" -- as="" doesn't read
well when the link type is "subresource"). Also, "subresource" is much
harder to type, at least for me. If we're left with deciding between
rel=subresource, rel=preload, and declare="", then basically the choice
becomes one of how important backwards-compatibility is: do we want
something we can deploy today, something we can deploy next year, or
something we can deploy next decade? The longer we can wait, the neater
the solution. The sooner we want it, the more we have to compromise.
The attribute dependson="" could probably also be refined. People have
suggested various names that could work:
uses=""
needs=""
dependson=""
dependencies=""
subresources=""
import=""
uses="", needs="", and dependson="" seem more or less equivalent. I'm a
bit dubious about adding an attribute that ends with "on" to avoid the
similarity with event handler attributes. dependencies="" and
subresources="" seem a bit long without giving an obvious benefit.
import="" seems reasonable, but I'm worried that it is too close to the
ES6 "import", CSS "@import", or HTML rel="import", which all have similar
but stronger semantics. Here we're not trying to actually effect an
import, we're just trying to let the browser know that a particular
element is going to come in useful when this element is invoked.
There have also been some proposals with names that don't really fit
grammatically, like depends="". I haven't considered those further.
Let's take the above example and add more nodes to the dependency tree,
and see how it looks with the various proposals.
rel=preload, as=..., uses=... -- the shortest names mentioned above:
<!-- core files -->
<script src="core.js" type=module id="core"></script>
<link rel=preload as=stylesheet href="core.css" id="core-css">
<!-- calendar files -->
<link rel=prelaod as=stylesheet href="calendar.css" id="cal-css"
uses="core-css">
<link rel=preload as=image href="imgs/cal.png" id="cal-sprites">
<script src="calendar.js" type=module
uses="core cal-css cal-sprites"></script>
rel=subresource, kind=... subresources=... -- has a nice consistent
symmetry, but man is it annoying to type:
<!-- core files -->
<script src="core.js" type=module id="core"></script>
<link rel=subresource kind=stylesheet href="core.css" id="core-css">
<!-- calendar files -->
<link rel=subresource kind=stylesheet href="calendar.css" id="cal-css"
subresources="core-css">
<link rel=subresource kind=image href="imgs/cal.png" id="cal-sprites">
<script src="calendar.js" type=module
subresources="core cal-css cal-sprites"></script>
rel=subresource, kind=..., needs=... -- less annoying, still annoying:
<!-- core files -->
<script src="core.js" type=module id="core"></script>
<link rel=subresource kind=stylesheet href="core.css" id="core-css">
<!-- calendar files -->
<link rel=subresource kind=stylesheet href="calendar.css" id="cal-css"
needs="core-css">
<link rel=subresource kind=image href="imgs/cal.png" id="cal-sprites">
<script src="calendar.js" type=module
needs="core cal-css cal-sprites"></script>
rel=preload, kind=..., needs=... -- similar to as/uses:
<!-- core files -->
<script src="core.js" type=module id="core"></script>
<link rel=preload kind=stylesheet href="core.css" id="core-css">
<!-- calendar files -->
<link rel=preload kind=stylesheet href="calendar.css" id="cal-css"
needs="core-css">
<link rel=preload kind=image href="imgs/cal.png" id="cal-sprites">
<script src="calendar.js" type=module
needs="core cal-css cal-sprites"></script>
declare="" and needs="", reusing the existing load mechanisms:
<!-- core files -->
<script src="core.js" type=module id="core"></script>
<link declare rel=stylesheet href="core.css" id="core-css">
<!-- calendar files -->
<link declare rel=stylesheet href="calendar.css" id="cal-css"
needs="core-css">
<img declare src="imgs/cal.png" id="cal-sprites">
<script src="calendar.js" type=module
needs="core cal-css cal-sprites"></script>
We do use kind="" on <track>, for something similar, which would be an
argument for kind="" over as="". Also, as="", while cute and, in context,
pretty nice looking, does suffer from lack of clarity when used out of
context (plus, consider the confusing with is="" from Web components).
Searching [link element as attribute] is not likely to get you as helpful
a set of results as [link element kind attribute]. It's really tempting to
just use the declare="" attribute, though, since that reuses so much
machinery and avoids having to intoduce kind="" at all.
It's harder to decide between needs="" and uses="". I think "needs"
probably has a slight edge only because it, to me at least, more strongly
implies that if the load of a dependency fails, the element cannot be
satisfied. uses="" sounds more opportunistic. For now, let's suppose we go
with needs="".
(As an aside, I should add that I welcome bike-shedding on all these
names. If you have an idea I haven't considered, or a way of looking at
the names that I haven't mentioned here, please don't hesitate to bring it
up. Now's the time, before anything gets implemented.)
The discussion above suggests that needs="", the attribute that defines
these dependencies, should take a space-separate list of IDs, rather than
URLs. This, though, brings in a new set of subtle questions. When are
these IDs resolved? Should they update dynamically? For consistency with
the rest of the platform, the answer should probably be yes, but this does
introduce "spooky action-at-a-distance" effects, which is unfortunate. For
example:
<link id=a rel=preload kind=image href="a.png">
<link id=b rel=preload kind=image href="b.png">
<script needs="a" ... id="demo">
...
</script>
<!-- later... -->
<script>
document.getElementById('a').id = 'c';
document.getElementById('b').id = 'a';
</script>
<!-- later... -->
<script>
document.scripts.demo.execute();
</script>
Which image(s) should be downloaded? If the browser is aggressively
precaching everything that something depends on, probably all of them; if
it's only fetching what is actually needed when it's needed, presumably
only b.png. ES6 modules make this a bit more complicated too, in that we
don't fully control when the normalize hook is run (which is where we'd
presumably evaluate these mappings).
In the example above, the <script> element has a "..." in its attribute
list, which brings us to the next and more thorny part of the whole issue:
how to tell the browser that certain resources are only to be loaded when
they are needed.
Normally, browsers aggressively download everything.
<link rel=stylesheet href="a.css">
<img src="a.png" alt="">
<script src="a.js"></script>
All three files will be immediately fetched and applied. In fact, it's
worse than that; the style sheet will block the script from executing, and
the script will block the parser from continuing to the rest of the page
(e.g. blocking a subsequent video from starting to play).
We have ways to prevent the blocking for <script>, namely defer="" and
async="". Their exact behaviour is a little subtle, but, broadly speaking,
the defer="" attribute delays the script until after the page has finished
loading, while the async="" attribute tries to run the script as fast as
possible without blocking. Style sheets don't currently have such a
mechanism, though it has previously been requested. Everything else, more
or less, loads like the async="" behaviour. (All of the above, including
'defer', also delay the 'load' event.)
So, to address most of the use cases described at the top of this e-mail,
we need a way to delay the application (and in some cases loading) of
resources until they are "needed", for some definition of needed.
Some of the use cases also need a way for us to de-dupe references to the
same resource, even across otherwise independent packages. For example,
two separate packages that both want to load jQuery, or two separate style
sheets for different parts of the app that both want to load a "reset"
sheet first. (The CSS case is not spoken about as much as the scripting
case, but it's still real, especially for big applications; see, for
instance, this talk:
https://www.youtube.com/watch?v=_MD1WQclOJM
...about Google+'s rather elaborate system to solve this.)
In the proposal from last year, I had suggested a whenneeded="" attribute
with three states: today's status quo, a value to delay the load and
execution until the script was needed (indicated by calling "execute()" on
the script element), and a value to delay the load until then and delay
the execution until everything depending on this script itself was also
ready to execute.
As discussed earlier in this e-mail, however, this is probably
insufficient. We probably need to just expose a way to control the load
policy for an element.
There's actually two somewhat orthogonal aspects to this. When to download
the resource, and when to execute or apply it. For some resources, when to
download it is irrelevant (e.g. inline scripts), and for some, when to
apply it is irrelevant (e.g. images).
For downloading, it again breaks down into several somewhat orthogonal
controls - when, and what priority:
- When to consider downloading it:
- don't wait, just get it immediately
- wait until either it's needed, or nothing that _is_ needed is
being downloaded (precaching)
- wait until it's needed, don't precache
- What priority to give the download:
- download it as soon as possible
- allow other downloads to take priority
That sort of maps to three booleans:
- fetch-asap vs fetch-when-needed
- precache vs no-precache
- high-priority vs low-priority
...except that 'precache' requires 'fetch-when-needed'.
You can alternatively view this as six states:
- download now at high priority (default)
- download when needed at high priority (fetch-when-needed)
- download when needed at high priority, but allow precaching
(fetch-when-needed, precache)
- download now at low priority (low-priority)
- download when needed at low priority (fetch-when-needed, low-priority)
- download when needed at low priority, but allow precaching
(fetch-when-needed, precache, low-priority)
For execution/application, there's basically one control, with five
levels (one of which is the equivalent of declare="", from earlier):
- execute this now, blocking subsequent scripts from executing until it
is done (this describes the legacy behaviour of <script> and style
sheets, and probably shouldn't be exposed. It also overrides the
download behaviour, since when you're blocked you need the resource as
soon as possible and so you won't wait, nor use a low-priority channel)
- execute as soon as possible after it is downloaded
- execute as soon as it is needed
- execute just before anything depending on this is executed
- don't ever execute this, this is a placeholder for something that will
be referenced from elsewhere that is just being listed here so that we
can preload it and reference it
The "execute as soon as possible after it is downloaded" and "execute as
soon as it is needed" options would obviously be equivalent when the
download option is "when-needed", but it would _not_ be the same for other
cases (e.g. it controls whether to execute after precaching or not, and
decides when to apply inline resources, which don't get downloaded in the
first place).
Let's give those five states straw-man names: block, use-asap,
use-when-needed, use-late, and declare.
The "low-priority" modifier applies to most of these values, and
"precache" applies to all those with fetch-when-needed. Expanding out all
the combinations, using square brackets to show different possible
combinations for the "low-priority" and "precache" values, we get:
block
use-asap [low-priority]
use-when-needed [low-priority]
use-late [low-priority]
declare [low-priority]
fetch-when-needed use-asap [low-priority] [precache]
fetch-when-needed use-when-needed [low-priority] [precache]
fetch-when-needed use-late [low-priority] [precache]
fetch-when-needed declare [low-priority] [precache]
These names are quite confusing. In particular, "use-when-needed" alone
makes it sound like it'll be fetched when needed too, not immediately. And
"fetch-when-needed use-when-needed" is pretty horrible for what might be a
pretty common case. (So common the earlier proposal just had a single
attribute for it, whenneeded="".)
Here's an alternative set of names for the same states. I used "async" for
"use-asap" because that's basically what <script async> today does. The
others are new names.
block
async [low-priority]
when-needed preload [low-priority]
late-run preload [low-priority]
declare preload [low-priority]
optimistic [low-priority] [precache]
when-needed [low-priority] [precache]
late-run [low-priority] [precache]
declare [low-priority] [precache]
Here, "preload" means "fetch it ASAP", and "precache" means "fetch it
whenever you want (but not later than when it's needed)". If you had one
of each of these, what order would they load in, assuming all the ones
that are marked as loading only when needed were requested after
everything else had loaded, and that only one resource could be loaded at
a time? It would be something like this, I think:
block
async
async low-priority
when-needed preload, declare preload
when-needed preload low-priority
late-run preload
late-run preload low-priority
optimistic precache
when-needed precache, declare precache
late-run precache
optimistic low-priority precache
when-needed low-priority precache
late-run low-priority precache
// (pause until they are marked as needed)
optimistic
when-needed, declare
late-run
optimistic low-priority
when-needed low-priority, declare low-priority
late-run low-priority
(I'm assuming "when-needed" and "declare" have the same importance in
terms of fetching priority.)
Even when you hide the low-priority lines, it's still a lot:
block
async
when-needed preload, declare preload
late-run preload
optimistic precache
when-needed precache, declare precache
late-run precache
// (pause until they are marked as needed)
optimistic
when-needed, declare
late-run
We clearly don't need all of these. In particular, we could merge
"preload" and "precache" so that it's more than a hint, but less than an
immediate request. This gets us down to basically four keywords plus
"async" and "block", which represent the default behaviours for most
interesting elements:
block
async
optimistic [precache] [low-priority]
when-needed [precache] [low-priority]
late-run [precache] [low-priority]
declare [precache] [low-priority]
We could also add a flag that says "always force a new download, rather
than deduping", to match current default behaviour of certain features.
Say, "force".
Here's how these would map to some existing features:
<link rel=stylesheet>: block force
<style>: block
@import: block force
<script src>: block force
<script src defer>: when-needed precache force; plus, the page load
itself triggers the script as being needed
<script src async>: async force
<link rel=icon>: when-needed precache
<img ...>: async force
<img ... hidden>: async low-priority force
So for example, if you had a style sheet that you only wanted to apply
when it was needed by some script, but which could be downloaded earlier
if the browser wanted to, and which should be deduped if there are
multiple instances of it loaded, you could declare it as:
<link rel=stylesheet href="foo.css"
load-policy="when-needed low-priority precache">
For resources that don't have an "execute" step, like images, there's no
concept of late execution. For these, optimistic, when-needed,
and late-run are all essentially the same, and "block" doesn't apply; the
choice is really between "fetch now", "fetch soon", and "fetch when
needed", aka async, when-needed precache, and when-needed.
Again, I'm not a great fan of these names. Bikeshed away.
To complement the dependency model and load policy, we need a few
additional features. There needs to be a way to indicate that something
that is waiting to be needed is in fact needed (separate from something
depending on it, that is). So probably a method like .execute(), though
it would be nice to have a name that could apply to all elements.
The browser also needs a way to say "I need this" for some elements, such
as images -- there, it would kick in when the element is being rendered.
It would also be nice to be able to have an API that lets you add elements
to another element's dependency list without having to add an ID and add
the element that way. (That would also allow cross-document dependencies,
which might be useful.) Maybe foo.addDependency().
To make this all work well with promises, it would also be nice to have an
API to say "add this promise as a dependency". This could be an overload
of the element-receiving one mentioned in the previous paragraph.
Unfortunately, as far as I can tell, a promise breaks the back-channel
logic. For example, consider this case:
<link rel=stylesheet href="foo.css" load-policy="when-needed" id=a>
<img src="bar.png" alt="..." load-policy="when-needed" id=b>
<script>
links.a.addDependency(images.b);
</script>
At this point, ideally, nothing would happen. Now suppose that we told the
style sheet link that it was needed. Ideally, the image would then
download itself also. But in practice, I don't see how we can actually do
that. There's no back-channel along the promise to inform the image that
it should now start downloading itself.
So I guess for promises as dependencies, we'd only have a way to wait on
the promise, not a way to also trigger the load that the promise
represents. That's probably sufficient for most cases if we also have a
way to add a dependency by ID.
To help hook into things that use promises, we should presumably have
.loaded and .ready attributes that return promises for when something has
executed/applied (.loaded, similar to onload) and when things are
prefetched and ready to go (.ready). We could pair that last one with a
new event, onready, for those who prefer the event model.
We also need a way to actually say that things should be executed. For
consistency with onload, I guess a .load() method.
Earlier in this e-mail I mentioned ES6 modules and HTML imports, and
pointed out that they both had dependency systems. If we add in the system
described above for HTML resources, we now have three. I think it's pretty
critical that we not require that browsers implement three redundant
dependency systems.
Since the more mature of the three is ES6, I've been trying to work on
fitting HTML imports and the system described above into the ES6 module
world. Mostly this just means defining the default behaviour of the ES6
loader hooks, though there's probably a few things that would need
changing at the ES6 module level to make it fully work (I've been sending
this feedback to the es-discuss list directly for those who want to follow
along over there).
The main thing that ES6 doesn't currently support is the ability to set
the dependencies ahead of time. The discussion below assumes that that
will be resolved. There's also a minor issue with being able to associate
metadata with a load when it's discovered as a dependency and when its
name is normalised, so that @import rules can work right.
Modulo those issues, the idea is that any fetch within the context of a
Web page would be added to the ES6 module loader mechanism.
The "normalize" hook would need a way to reference elements by ID. There's
two obvious ways to do that: support any string that matches an ID as
being an ID, and support any string starting with a "#" as being an ID.
The former is neater-looking:
<link rel=stylesheet id=foo ... load-policy="when-needed">
<script type=module>
import styles from "foo";
</script>
...but means that we're now overloading the string passed to import as
multiple things (package locators, IDs, and URLs) in a rather ambiguous
way. So the hash idea is probably better:
<link rel=stylesheet id=foo ... load-policy="when-needed">
<script type=module>
import styles from "#foo";
</script>
It's important to distinguish this from a URL, though; I don't expect this
to work:
<!-- in foo.html -->
<link rel=stylesheet id=foo ... load-policy="when-needed">
<!-- in bar.html -->
<link rel=import href="foo.html">
<script type=module>
import styles from "foo.html#foo"; // the #foo here presumably has no effect?
</script>
But what should the "#foo" do? Probably it should throw, but we could
imagine maybe having the "normalize" hook wait until the import is done?
("normalize", by default, would probably also need to support two other
things:
1. absolute and scheme-relative URLs
2. some sort of relative naming for ES6 modules themselves, so that
you can do things like:
import "jquery";
import "../base/utils";
import "login/login";
...and have it get "jquery.js" from some predeclared registry,
"../base/utils.js" relative to the current script (not the doc!), and
"login/login.js" in the same way.
I'm not really sure how to do the package part of this.)
The other hooks do pretty much the obvious things, except maybe
"instantiate" which has to figure out how to import something once it has
its MIME type.
Pulling all of the above together, here's the tentative proposal:
These "loadable" elements:
<script>, <link>, <style>, <video>, <img>, <object>, <iframe>, <audio>
...get the following new attributes:
needs="" Gives a list of IDs of other elements that this one
needs, known as The Dependencies. Each dependency
is added to this element's [[Dependencies]] in the
ES6 loader.
load-policy="" The load policy. Consists of a space-separated
set of keywords, of which one may be from the
following list: block, async, optimistic,
when-needed, late-run, declare. The other
allowed keywords are precache, low-priority,
and force. (Maybe we disallow "block" and
"force" since they're for legacy only.)
Different elements have different defaults.
"precache" isn't allowed if the keywords
"block" or "async" are specified, since those
always load immediately.
load-settings="" A JSON-encoded dictionary to pass to the Request
constructor.
...and API:
.addDependency() Passed a promise, makes this element depend on that
promise. Passed a "loadable" element, does the same
as if that element's ID was mentioned in needs="".
.load() Mark the element as needed, and apply or execute it
as soon as possible. Returns the new .loaded
promise (any earlier one is rejected).
.ready Promise indicating calling load() will immediately
apply or execute when load() is called.
.loaded Promise indicating that the element has applied or
executed.
.request The current Request object, if a fetch has been
started.
.needs reflects needs, maybe as a custom object, or
otherwise as a DOMTokenList
.loadPolicy reflects load-policy, maybe as a custom object, or
otherwise as a DOMTokenList
.loadSettings reflects load-settings, maybe as a custom object
These elements can be in six states. The first five are sequential;
elements try to go through them in turn:
- idle (the initial state at creation time)
- prefetching...
- ready (matches the .ready promise)
- loading...
- loaded (matches the .loaded promise)
...and the sixth is "error", meaning something failed permanently.
Setting src="", or whatever causes the element's state to be reset,
immediately rejects the preexisting .loaded promise and creates a new
one, moving the element back to "idle".
When an element is created, it's added to the ES6 module registry. (When
one of these elements has its ID or URL changed, its entries in the
registry are updated.) The ES6 LoadModule() operation is called for this
module (that's how it is added to the registry).
Except if the load policy has the "force" flag, when the element is added
to the registry it's done in such a way as to rely on ES6 deduping.
An element can be needed. By default it's not, unless it has a load-policy
of "block" or "async". Upon creation, and when its needs="" is changed
while the element is still not ready, or when another element's ID is
changed and that matches an ID in an element's needs="", the element's
[[Dependencies]] list is updated accordingly.
When an element is marked as needed, all the things in its
[[Dependencies]] get marked as needed also.
An element in "idle" moves to "prefetching" if the load-policy is
optimistic and the browser has nothing better to do, or the load-policy
has "precache" declared and the browser has nothing to do, or the element
is marked as "needed" somehow.
An element's "fetch" hook blocks until the element reaches "prefetching".
Once it does, if this is something to download, it creates a Request
object from the load-settings="" attribute and the appropriate URL. For
inline scripts and styles, the body comes from the element. Once the fetch
hook finishes, an event is to be fired at the element. Once all its
dependencies are ready, another event is to be fired at the element.
When a script is needed, once it's ready, it is EnsureEvaluated() (see
the ES6 spec for details).
When scripts run, if they throw an uncaught exception then they go to the
"error" state and that prevents any dependencies from resolving. If
something is being loaded and it depends on something that's reached
"error", it aborts loading. Something that depends on a resource in the
"error" state won't load, it'll just transition to "error" straight away.
(Or should it just wait, so you can remove the dependency and unblock it?)
Changing the "load-policy" doesn't reset the element's state, it just
causes it to resume from its current state with the new policy. If the new
policy is irrelevant (because it applies to a state earlier than the
current one), then nothing interesting happens. For instance, moving from
"block" to "declare" after the file has already been executed does nothing.
For style elements (and most elements, in fact), the "execute" callback
does nothing. The StyleSheet object is created earlier. The script is
applied once it is both needed and ready (in place of EnsureEvaluated()).
While it is marked with a load-policy of "declare", subsequent fetches of
the same URL in a style sheet context in the same Loader will use the same
file, not refetch it.
Certain loadable elements can also be told to execute by the browser even
when they are awaiting being needed. Notably, <video>, <audio>, <img>,
<object>, and <iframe> will self-need themselves if the come into view.
The <link rel=preload> feature is given an attribute, kind="", which it
can use to determine how to parse the file (image, style sheet, HTML
import, JS script, JS module, ...).
Documents add things like synchronous scripts, style sheets, deferred
scripts, images, etc, to their dependency list while they are loading.
When a Document loads, all the <script defer> elements are told they
are needed.
Elements that aren't one of these "loadable" elements that end up being
imported as ES6 modules act as follows:
- fetch: blocks until the ID is visible
- instantiate: returns the element
By default, the priority of loads is based on the load policy and whether
the element is needed or not.
Here's how this would handle the use cases listed above.
> [Use-case F:] A website has a page where media is the primary content.
> It would like to make sure that media is downloaded before JS [e.g.
> flickr, youtube, facebook photos]
<!DOCTYPE HTML>
<html>
<title>Photo 23 in My Gallery</title>
<body>
<h1>Photo 23</h1>
<p><img src="photo23.jpeg" alt="..."></p>
<script src="more-features.js" load-policy="low-priority"></script>
</body>
> [Use-case G:] A website knows there's a piece of Javascript code that
> the user might need if they click on a part of the page. The developer
> would like to have the user download it, but not at the expense of other
> resources.
<script src="button-reaction.js" id="reaction"
load-policy="when-needed precache low-priority">
// button-reaction.js defines react()
</script>
<button type=button
onclick="document.scripts.reaction.load().then(
function() { react(); })"> Part of the Page </button>
> [Use-case H:] A website is prefetching photos in a photo album and would
> like to make sure these images are lower priority than images the user
> is actually viewing.
<img src="photo1.jpg" alt="..." load-policy="when-needed precache">
<img src="photo2.jpg" alt="..." load-policy="when-needed precache">
<img src="photo3.jpg" alt="..." load-policy="when-needed precache">
<img src="photo4.jpg" alt="..." load-policy="when-needed precache">
<img src="photo5.jpg" alt="..." load-policy="when-needed precache">
As they come into view, they'll become needed automatically. When they are
not needed, they get precached if that wouldn't get in the way of other
things getting loaded.
On Mon, 28 Jul 2014, Ben Maurer wrote:
>
> [Use-case I:] Facebook uses an automated pipeline to decide what CSS/JS
> files to package together. If we could pass a custom header in the
> request for a CSS file (for example: what part of the page caused that
> file to be loaded) we could use this information in our packaging system
> to make smarter decisions.
<link rel=stylesheet href="..."
load-settings='{ "headers": { "X-Facebook-Blame" : "<head>" } }'>
...or some such. The exact syntax of load-settings="" isn't something I've
studied closely. It might make sense to have a more dedicated syntax,
since JSON doesn't work well in HTML attributes due to quoting rules.
>From script:
var style = document.createElement('link');
style.rel = 'stylesheet';
style.href = '...';
style.loadSettings = { "headers":
{ "X-Facebook-Blame" : "<head>" }
}.toJSON();
...or some such. Again, it might make sense to have a dedicated API for
loadSettings which would make this better. Also, medium term, Tab is
working on a StyleSheet object and constructor.
> [Use-case J:] The way we render pages at Facebook [is essentially that
> we] flush sections of HTML with a list of CSS and JS dependencies for
> each section. The HTML is only rendered once these resources are loaded.
We could have dedicated features for this (like making any element depend
on any other, making <div>s whose dependencies aren't met be display:none,
or even having :loaded/:ready pseudo-classes to match elements based on
their dependencies' statuses) but for now, even with the stuff above, the
simplest solution is probably more or less what you'd do now:
<section hidden class="foobar">
<!-- this is the section of HTML mentioned in the use case -->
<!-- each dependency is listed explicitly: -->
<script>
// Prior to this we must have loaded a script that defines two
// functions. The first adds style sheets, the second adds scripts.
// They return promises. All the things added by these functions are
// fetched right away.
var promises = [];
// To add a style sheet, you need to know the URL to the sheet,
// any sheets it depends on, and the relative order amongst
// all the sheets in the project
promises.push(addStyleSheet('common.css', [], 1));
promises.push(addStyleSheet('foobar.css', ['common.css'], 4));
// To add a script, you just need the URL and its dependencies.
promises.push(addScript('common.js', []));
promises.push(addScript('foobar.js', ['common.js']));
var section = document.currentScript.parentNode;
Promise.all(promises).then(function () {
section.hidden = false;
})
</script>
</section>
Depending on the size of your total dependency tree, you could predeclare
it in the <head> and just refer to that from import statements, something
like:
<link rel=stylesheet load-policy="declare when-needed"
href="common.css">
<link rel=stylesheet load-policy="declare when-needed"
href="foobar.css" needs="common.css">
<script src="common.js" load-policy="declare when-needed"></script>
<script src="foobar.js" load-policy="declare when-needed"
needs="common.js"></script>
...and then later when you send the markup:
<section hidden class="foobar">
<!-- this is the section of HTML mentioned in the use case -->
<!-- each dependency is listed explicitly: -->
<script type="module">
import "./foobar.css";
import "./foobar.js";
document.currentScript.parentNode.hidden = false;
</script>
</section>
If you gave the <link> and <script> blocks IDs, you could refer to them
that way instead, to be more explicit:
<link rel=stylesheet load-policy="declare when-needed"
href="common.css" id=common-css>
<link rel=stylesheet load-policy="declare when-needed"
href="foobar.css" id=foobar-css
needs="common.css">
<script src="common.js" load-policy="declare when-needed"
id=common-script></script>
<script src="foobar.js" load-policy="declare when-needed"
needs="common.js" id=foobar-script></script>
...
<section hidden class="foobar">
<!-- this is the section of HTML mentioned in the use case -->
<!-- each dependency is listed explicitly: -->
<script type="module">
import "#foobar-css";
import "#foobar-script";
document.currentScript.parentNode.hidden = false;
</script>
</section>
However, giving all the dependencies ahead of time doesn't really scale
for even medium-sized sites, unfortunately.
> [Use-case K:] We have a few other use cases for this type of dependency
> (for example, we have a method where you can say "call this callback
> once resources X, Y and Z are requested").
Promise.all([X.loaded, Y.loaded, Z.loaded]).then(thisCallback)
> [Use-case L:] A web page wants to load and execute a script widget.js if
> the script is already cached in the browser. However, it wants to load
> other essential assets such as images first if it's not already in the
> cache except as long as the user had not started interacting with the
> parts of the page that require widget.js.
<script id=w src=widget.js load-policy="optimistic low-priority">
</script>
<div> <!-- part of the page that needs the widget -->
<script>
var div = document.currentScript.parentNode;
function startWidget () {
document.scripts.w.load();
div.removeEventListener('mouseover', startWidget, true);
div.removeEventListener('focus', startWidget, true);
};
div.addEventListener('mouseover', startWidget, true);
div.addEventListener('focus', startWidget, true);
</script>
</div>
> [Use-case M:] Being able to specify that an image/video should only be
> downloaded "on demand" (aka "lazily"), i.e. when it's in view, or about
> to be in view. Use case is both to lower bandwidth in cases of long
> pages where the user doesn't always scroll to the bottom, as well as
> make sure to fill the network pipe with the most important resources
> first.
<img src="..." alt="..." load=policy="when-needed">
> [Use-case N:] Being able to specify that a stylesheet should not block
> rendering. Use case is to preload stylesheets that will be used by
> content that isn't rendered in the initial view, but that might be
> rendered later.
There's various options here. If we're going to explicitly invoke the
style sheet in due course:
<link rel=stylesheet href="..." id="mystyle"
load-policy="when-needed precache">
// when needed:
document.getElementById('mystyle').load();
If we're just hoping it'll be loaded slower, but will be applied
automatically:
<link rel=stylesheet href="..." id="mystyle"
load-policy="async low-priority">
Medium term we might want to consider letting random elements depend on
the style sheet, not just <img>, so that when the elements that do use
this come into view, the style sheet can be forced on (and maybe the
aforementioned pseudo-classes can be used to display:none the element
while it's loading the style sheet or something.)
> [Use-case O:] Being able to specify some form of prioritization for
> resources like (non-blocking) stylesheets, (non-blocking) <script>s,
> images, video, iframes etc. Use case is making sure to fill the network
> pipe with the most important resources first. Possibly a simple
> prioritization like "needed for initial rendering/not needed for initial
> rendering" is enough, possibly there are needs for more finegrained
> prioritization like "needed for initial rendering/needed for page
> feature X that is commonly used, needed for other".
The low-priority flag should help with this. To give more control, if
RequestInit (part of Fetch) exposes HTTP2's priorities, authors can
directly manipulate that.
> [Use-case P:] download dynamic page components (e.g. maps) only on
> larger devices.
Long term, we could add a media="" attribute to <script> to make this
easier. Short term, you can do it with scripts by checking the width of
the device and calling load() on the script if you want it.
If you're a browser vendor who wants to implement <script media>, please
comment on this bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23509
> [Use-case Q:] I am dynamically loading one of those social widgets that,
> upon load, automatically scans a page and renders social buttons. I need
> to be able to preload that script so it's ready to execute, but decide
> when I want it to run against the page. I don't want to wait for true
> on-demand loading, like when my user clicks a button, because of the
> loading delay that will be visible to the user, so I want to pre-load
> that script and have it waiting, ready at a moment's notice to say "it's
> ok to execute, do it now! now! now!".
You'd declare it like this:
<script ... load-policy="when-needed precache" id=w>
...and run it like this:
document.scripts.w.load();
> [Use-case S:] One CMS plugin wants to load "A.js" and "B.js", where B
> relies on A. Both need to load in parallel (for performance), but A must
> execute before B executes. I don't control A and B, so changing them is
> not an option. This CMS plugin [wants] to wait for some
> user-interaction, such as a button click, before executing the code. We
> don't want there to be any big network-loading delay visible to the user
> between their click of the button and the running of that plugin's code.
<script src="a.js" load-policy="when-needed precache" id=a>
<script src="b.js" load-policy="when-needed precache" needs=a id=b>
<input type=button onclick="document.scripts.b.load()">
> Another CMS plugin on this same page wants to load "A.js", "C.js", and
> "D.js". This plugin doesn't know or care that the other plugin also
> requests "A.js". It doesn't know if there is a script element in the
> page requesting it or not, and it doesn't want to looking for it. It
> just wants to ask for A as a pre-requisite to C and D. But C and D have
> no dependency on each other, only a shared dependency on A. C and D
> should be free to run ASAP (in whichever order), assuming that A has
> already run [once] some user-interaction that initiates the load of A,
> C, and D. This user interaction may be before the other plugin requested
> A, or after it requested A.
First the previous part:
<script src="a.js" load-policy="when-needed precache" id=a1>
<script src="b.js" load-policy="when-needed precache" needs=a1 id=b1>
<input type=button onclick="document.scripts.b1.load()">
Now this plugin:
<script src="a.js" load-policy="when-needed precache" id=a2>
<script src="c.js" load-policy="opportunistic precache" needs=a2 id=c2>
<script src="d.js" load-policy="opportunistic precache" needs=a2 id=d2>
<input type=button
onclick="document.scripts.c2.load(); document.scripts.d2.load();">
Because the load-policy doesn't contain "force" (which would be in the
default for scripts), the second <script src="a.js"> defers to the first
one.
> "A.js" can be requested relatively (via a <base> tag or just relative to
> document root) or absolutely, or it might be requested with the
> leading-// protocol-relative from, taking on whatever http or https
> protocol the page has, whereas other references to it may specify the
> prototcol.
That just works with the above, since the src="" attribute is resolved
before being compared.
> These plugins can't guarantee what ID's or classes they use are reliably
> unique without undue processing burden.
Ah. This is more problematic.
If the plugins are put into HTML imports, this works because imports have
their own ID scope. Is that sufficient?
> [Use-case T:] I have two different calendar widgets. I want to pop one
> of them up when a user clicks a button. The user may never click the
> button, in which case I don't want the calendar widget to have ever
> executed to render. [...]
>
> It'd be nice if both calendar widgets were built sensibly so that
> loading the code didn't automatically render. One of them IS, the other
> is unfortunately mis-behaving, and it will render itself as soon as its
> code is run. [...]
>
> Furthermore, these two widgets are not "equal". Perhaps one is better
> for smaller browser window sizes, and the other is better for larger
> browser windows. [...]
>
> Regardless, the point is, there's run-time conditions which are going to
> determine if I want to execute calendar widget A or B, or maybe I never
> execute either. But I want them both preloaded and ready to go, just in
> case, so that if the user DOES need one, it's free and ready to execute
> with nearly no delay, instead of having to wait to request as I would
> with only on-demand techniques.
<script src="calendar1.js" load-policy="when-needed precache" id=cal1>
</script>
<script src="calendar2.js" load-policy="when-needed precache" id=cal2>
</script>
<script>
function showCalendar() {
if (useCalendar1)
document.scripts.cal1.load();
else
document.scripts.cal2.load();
}
</script>
<input type=button onclick="showCalendar()">
> [Use-case U:] I have a set of script "A.js", "B.js", and "C.js". B
> relies on A, and C relies on B. So they need to execute strictly in that
> order. [Now], imagine they progressively render different parts of a
> widget. [...] I only want to execute A, B and C once all 3 are preloaded
> and ready to go. It's [...] about minimizing delays between them, for
> performance PERCEPTION.
>
> [For example, one of them might start playing a video, and another might
> introduce the <canvas> slides for that video. You want all of the
> relevant scripts to be run at once, so there's no point where the page
> has a <video> element but doesn't have the <canvas>.]
<script src="A.js" id=A load-policy="late-run"></script>
<script src="B.js" id=B load-policy="late-run" needs=A></script>
<script src="C.js" id=C load-policy="async" needs=B></script>
> [Use-case V:] you have a string of scripts ("A.js", "B.js", and "C.js")
> loading which constitute a dependency chain. A must run before B, which
> must run before C. However, if you detect an error in loading, you stop
> the rest of the executions (and preferably loading too!), since clearly
> dependencies will fail for further scripts, and the errors will just
> unnecessarily clutter the developer console log making it harder to
> debug.
That's the built-in behaviour.
> [Use-case W:] some developers have even requested to be able to stop the
> chain and prevent further executions if the script loads, but there's
> some compile-time syntax error or run-time error that happens during the
> execution. For them, it's not enough for B to simply finish loading
> successfully, but that it must fully execute without error.
If something throws, it'll trigger the same failure behaviour as failing
to load at all.
> [Use-case X:] not all dependencies are JS files, e.g. authors use
> plugins to load template files, JSON, images, etc.
Images are handled since you can use an <img> element as the target of a
needs="" attribute. You can add dependencies on manually-started loads
using promises; these won't automatically trigger the loads, but they
will cause the loads to wait.
> [Use-case Y:] not all dependencies are usefully satisfied immediately
> after their JS file is loaded, e.g. some libraries may need asynchronous
> initialization.
You can add a promise as a dependency.
> [Use-case Z:] Another common kind of dependency scripts have is presence
> of certain element in the DOM, e.g. `dropdown-menu.js` may require `<nav
> id="menu">` to be in the document _and_ have its content fully parsed
> before the script can run.
needs="" can point to any element by ID; it'll only be resolved once the
ID is present in the DOM.
On Tue, 27 Aug 2013, Ian Hickson wrote:
>
> Jake also mentioned these requirements:
>
> | - Provides an adoption path for browsers that don't support the new
> | feature (happy for the fallback to be blocking document-order
> | execution)
That's the fallback for the declarative features. (This might actually
be a problem for load-policy=declare.)
> | - Is discoverable by pre-parsers (so async=false and old-IE's
> | readystate methods aren't enough)
This is true for the declarative cases, at least. Note though that if
we make everything async (as this essentially would), preparsing
becomes much less important.
> And Kyle mentioned this scenario that we need to handle as well (not
> strictly a use case, more a variant on the above use cases):
>
> > I want to preload a script which is hosted somewhere that I don't
> > control caching headers, and to my dismay, I discover that they are
> > serving the script with incorrect/busted/missing caching headers.
We can handle this by defining the behaviour of "precache" more
explicitly, or putting options or load-settings="", but I'm not sure
what behaviour we want exactly. What headers should we ignore? When?
On Wed, 23 Jul 2014, Ben Maurer wrote:
> On Tue, Jul 22, 2014 at 5:33 PM, Ian Hickson <ian@hixie.ch> wrote:
> >
> > Why not:
> >
> > var mystyle = E('link', { rel: 'stylesheet', href: 'my.css',
> > whenneeded: true });
> > document.body.appendChild(mystyle);
> > var myfetch = mystyle.fetch;
> > ...
>
> Yeah, I think that API would be perfect (assuming that whenneeded=true
> initiates the fetch, but not the load into the document). In combination
> with allowing the user to specify an attribute with a set of parameters
> to the fetch algorithm (eg, a custom header) I think that would cover
> the use cases I was thinking of.
So this would be:
var mystyle = E('link',
{ rel: 'stylesheet', href: 'my.css',
'load-policy': 'declare prefetch',
// declare prevents it from ever being applied
'load-settings': '...'
// this is your custom headers, etc
});
document.body.appendChild(mystyle);
mystyle.load(); // triggers the fetch
// since it's marked "declare", it doesn't get automatically applied
mystyle.loaded.then(function () {
// we can remove the 'declare' part of the policy to make it apply:
mystyle.loadPolicy.remove('declare');
// alternatively we could create a new <link rel=stylesheet> element
// and insert that; since the URL is the same it would reuse what it
// got for mystyle instead of starting anew.
});
var myfetch = mystyle.request;
// you can manipulate the priority or whatever with myfetch
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 23 August 2014 00:46:35 UTC