RE: [ResourcePriorities] Spec updates

On 9/10/13 6:11 PM, William Chan wrote:
> I appreciate the desire to allow conformance testing, but I'm confused on a few levels:
> * It seems weird on the one hand to call this a hint (and I like that it's just a hint), but on
> the other hand use MUST clauses.

We had discussed this on the conference call as well, and most had agreed that it¡¯s a bit confusing to have a MUST clause and be a hint at the same time. I have reverted the MUST clause back to a SHOULD clause.


From: William Chan (³ÂÖDzý) []
Sent: Tuesday, September 10, 2013 6:11 PM
To: Jatinder Mann
Subject: Re: [ResourcePriorities] Spec updates

Thanks for the reply Jatinder. Sorry for my dumb comments, I suspect I must be missing some context or am otherwise confused about the matters. I appreciate you taking the time to explain.

On Tue, Sep 10, 2013 at 5:02 PM, Jatinder Mann <<>> wrote:

There had been some feedback that without any MUST clauses the spec makes it very difficult to test implementation conformance. One of our goals was to make lazyload a hint to the user agent, such that the user agent could use that hint in cases of network contention to reduce the download priority of a resource. Similarly, in cases of no network content, the user agent could choose to ignore the lazyload hint, and download the resources as if the lazyload attribute wasn¡¯t specified.

I appreciate the desire to allow conformance testing, but I'm confused on a few levels:
* It seems weird on the one hand to call this a hint (and I like that it's just a hint), but on the other hand use MUST clauses.
* I don't see how testing would actually work. AIUI, network contention is intentionally vague and left to the implementor's discretion. How can you write a test for a MUST clause that is conditioned on something that is intentionally ambiguous. Are you going to expose a JS API to force the user agent to act as if there was network contention? In other words, it sounds like people would like to test "If X, then the user agent MUST do Y", but there is no way to control condition X.

I think the current spec text with the MUST clause instead of the MAY clause still maintains that spirit. The term network resource contention is defined as ¡®when the User Agent determines there is a conflict over access to network resources¡¯, so the user agent can decide to ignore the hint if it doesn¡¯t believe this is a case of network resource contention.

This feature is useful with HTTP1.1 as well, so we shouldn¡¯t limit it to HTTP/2.

I suspect there's some confusion here. I'm not suggesting this feature is not useful with HTTP/1.X. I can well see its use. Rather, I'm suggesting that this feature, as specced with the MUST, is harmful to HTTP/2. HTTP/2 already solves a lot of the contention issues by using prioritized multiplexing. Since HTTP/1.X doesn't have prioritized multiplexing, the way user agents typically achieve prioritization is by reducing contention by delaying downloads. So yes, it's helpful for HTTP/1.X. But it's harmful to HTTP/2 since there's no reason to delay the download, just issue it ASAP with the appropriate priority level.


From:<> [<>] On Behalf Of William Chan (???)
Sent: Sunday, September 1, 2013 3:56 PM
To: Jatinder Mann

Subject: Re: [ResourcePriorities] Spec updates

I have concerns about section 4.2 (
The lazyload attribute indicates the priority order in which the User Agent will download the resource associated with the element in cases of network resource contention.

If the lazyload attribute has been specified on an element and the User Agent determines that there is network resource contention, the User Agent MUST delay downloading the resource until after all other elements without the lazyload attribute that will be fetching a resource have started downloading.

In particular, I dislike this MUST, or perhaps I dislike the "delay downloading". This is vague and perhaps too restrictive. Due to how resource discovery works, resources with the lazyload attribute set may be discovered before resources without said attribute. I don't see how to enforce this MUST at all. And I don't know that it makes sense. Also, I don't see what's wrong in HTTP/2 with fetching a resource with the lazyload attribute before a resource without the attribute, as long as the priority is appropriately tagged in HTTP/2.


On Tue, Aug 20, 2013 at 4:09 PM, Jatinder Mann <<>> wrote:
Based on feedback from the working group, I have made some updates to the Resource Priorities spec,

-          Added the postpone attribute

The use case of never downloading a resource until its viewable by the user seems compelling from a system resources, server resources, and user bandwidth (e.g., mobile user) scenarios, but it does feel functionally different from the lazyload concept, where in cases of network contention connections are given to higher priority resources. I¡¯ve added a new postpone attribute to describe the case where we don¡¯t want resources to be downloaded if they aren¡¯t formatted to be visible or are not in the viewport. This attribute only applies to resources that can be laid out.

-          Defined script download and execution behavior

For the script element, I¡¯ve added more details on its expected execution behavior. The lazyload attribute delays downloading script in network contention scenarios, and will execute the script asynchronously soon as its available. Lazyload in this way behaves more closely to async than defer. I was initially considering changing the script execution behavior based on whether lazyload is used with defer or async (e.g., <script async lazyload> or <script defer lazyload>, but for now I have left it to be more closely aligned with async. As defer scripts take ordering into account, we would need to create a separate queue for <script lazyload defer> scripts, otherwise any <script defer> that came after a <script lazyload defer> would implicitly be lazyloaded as well.

-          Added MUST clauses

There was feedback that if the spec only has optional clauses, there will be very little to test. I have updated the spec to have MUST clauses, but have left the definition of the network resource contention and visibility generic enough that User Agents can choose to optimize here as needed.

-          Updated events behavior

The load event of the Document isn¡¯t delayed by resources with lazyload or postpone. In case developers are interested in tracking when all of their lazyloaded resources have actually loaded, I have specified a lazyloaded event that fires at that time. I haven¡¯t provided a similar event for postpone as I am assuming most developers would want to track those using load events on the element directly.

-          Added both IDL and content attributes

I¡¯ve made the attributes both IDL and content attributes, to be consistent with other similar attributes and help with feature detection.

-          Added use cases to introduction section

I have added more use cases and examples to the introduction section.

Please review and provide feedback.


Received on Saturday, 28 September 2013 00:48:17 UTC