W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2014

Re: [whatwg] Preloading and deferred loading of scripts and other resources

From: Ryosuke Niwa <rniwa@apple.com>
Date: Sat, 13 Sep 2014 11:02:19 -0700
Message-id: <A9908C5C-0684-4799-B839-12543C67C2E2@apple.com>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg <whatwg@lists.whatwg.org>

On Sep 8, 2014, at 1:33 PM, Ian Hickson <ian@hixie.ch> wrote:

> I got some feedback on my last e-mail to the effect that having the 
> proposal sandwiched between the rationale and the examples of how it would 
> be used made it hard to find, so I'm reproducing the proposal here 
> (slightly updated based on feedback):
> ---------------------------------------------------------------------------
> 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.
>   loadpolicy=""     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. The
>                     keywords' meanings are as follows:
>                      block - stop parsing until this resource is
>                      applied
>                      async - fetch now, apply asap
>                      optimistic - fetch when needed, apply asap
>                      when-needed - fetch when needed, apply when
>                      needed
>                      declare - fetch when needed, don't apply
>                      precache - for "fetch with needed", consider
>                      fetching earlier
>                      low-priority - let other things go first
>                      force - always fetch anew, don't de-dupe

I haven't discussed in detail with my colleagues but my impression is that we're quite concerned about the number of load policy options and the complexity they introduce.

I'm not certain if there is a value in having a load policy for "fetch when needed" since that could be achieved by inserting an script/style/etc... element when needed.  Are there any use cases for having script/style/etc... elements that before they start fetching respective sub resources?

It also appears that "apply when needed" can also be achieved by inserting link[rel=preload] first and later inserting an element of the appreciate type since the resource would have been cached by the browser at that point in practice.  If we wanted to make that explicit, we could add a method like loadFromPreload to script and syle elements and have it take link[rel=reload].

These two changes should dramatically reduce the number of load policies we need.

- R. Niwa
Received on Saturday, 13 September 2014 18:02:45 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:23 UTC