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 <jmann@microsoft.com> wrote:

>  Will,****
>
> ** **
>
> 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.


> ****
>
> ** **
>
> Thanks,****
>
> Jatinder****
>
> ** **
>
> *From:* willchan@google.com [mailto:willchan@google.com] *On Behalf Of *William
> Chan (???)
> *Sent:* Sunday, September 1, 2013 3:56 PM
> *To:* Jatinder Mann
> *Cc:* public-web-perf@w3.org
>
> *Subject:* 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****
>
>  ** **
>