Different aspects of priority are expressed in some of Ian’s loadpolicy attributes (block, async, optimistic, low-priority). Currently web browsers use the type of loadable element to determine priority. In Ilya’s proposal this can be found in the “as” attribute in the case of LINK rel=preload. While it’s not ideal, this approach at least allows us to get agreement on preload without having to get agreement on a new comprehensive spec on request prioritization. I’m just agreeing that the current preload spec seems like a good first step and we should go ahead with it once issues are resolved if we can get agreement from implementors.
Thanks, Peter On Sep 13, 2014, at 2:02 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > 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 >
