Re: [ResourcePriorities] Spec updates

I have concerns about section 4.2 (
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#lazyload-attribute
):
"""
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.

Cheers.


On Tue, Aug 20, 2013 at 4:09 PM, Jatinder Mann <jmann@microsoft.com> wrote:

>  Based on feedback from the working group, I have made some updates to
> the Resource Priorities spec,
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html:
> ****
>
> ** **
>
> **-          **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.****
>
> ** **
>
> Thanks,****
>
> Jatinder****
>