On Sep 8, 2014, at 1:33 PM, Ian Hickson <i...@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

Reply via email to