Re: [ResourcePriorities] Spec updates

Thanks. Glad to see that.


On Fri, Sep 27, 2013 at 8:47 PM, Jatinder Mann <jmann@microsoft.com> wrote:

>  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.****
>
> ** **
>
> Thanks,****
>
> Jatinder****
>
> ** **
>
> *From:* William Chan (陈智昌) [mailto:willchan@google.com]
> *Sent:* Tuesday, September 10, 2013 6:11 PM
>
> *To:* Jatinder Mann
> *Cc:* public-web-perf@w3.org
> *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 <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****
>
>   ****
>
>  ** **
>