- From: <bizzbyster@gmail.com>
- Date: Mon, 15 Sep 2014 13:43:29 -0400
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Ian Hickson <ian@hixie.ch>
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 <rniwa@apple.com> wrote: > > 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 Monday, 15 September 2014 17:44:17 UTC