Re: [ResourcePriorities] Lazyload spec clarifications and suggestions

Going over the ResourcePriorities spec, it doesn't seem like there are
guaranties regarding script execution order, nor any guaranties that
"lazyload" scripts will be executed at all.
In order to satisfy the (much needed) "analytics script" use-case, authors
need a guaranty that the script will eventually run, assuming that the user
doesn't leave the page before that.

Regarding execution order, the fact that these scripts will run after all
other scripts is implied, since it is specified that they should be
downloaded after all other scripts, but not stated explicitly. I'm not sure
this is critical for authors, as long as a "onload" event on the lazyloaded
script can be used to know when it was actually downloaded. Authors should
simply expect it to run later in the page load cycle, and not depend on
lazyloaded scripts before their "onload" fired.

Regarding execution guaranties, currently the spec says:
"If the lazyload<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#dom-lazyload>
 attribute has been specified on a supported
element<http://www.w3.org/TR/html5/infrastructure.html#html-elements>,
and the bounding box of the
element<http://www.w3.org/TR/html5/infrastructure.html#html-elements>
 is outside of the document's viewport, or the
element<http://www.w3.org/TR/html5/infrastructure.html#html-elements>
 has been styled such that its
display<http://www.w3.org/TR/CSS2/visuren.html#display-prop>
 property is set to none, in addition to waiting until after all other
elements <http://www.w3.org/TR/html5/infrastructure.html#html-elements> without
the lazyload<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#dom-lazyload>
 attribute that will be
fetching<http://www.w3.org/TR/html5/fetching-resources.html#fetch>
 a resource have started downloading, the User Agent MAY further delay
downloading that resource until either the bounding box of the
element<http://www.w3.org/TR/html5/infrastructure.html#html-elements>
 is inside of the document's viewport, or the
element<http://www.w3.org/TR/html5/infrastructure.html#html-elements>
 has been styled such that its
display<http://www.w3.org/TR/CSS2/visuren.html#display-prop>
 property is no longer set to none."

As far as I understand it (and I may be wrong), script elements have no
bounding box and no display property, so there's no "in the viewport"
notion for them. That could be interpreted as saying that browsers can
decide to never download and run lazyload scripts, and still be compliant
with the spec. The same also applies to "link" elements.
I don't think this is the text's intent. Is it possible to change the
wording of the above paragraph to clarify the "no bounding box" case?

Yoav







On Thu, Jul 18, 2013 at 2:17 AM, Bruno Racineux <bruno@hexanet.net> wrote:

> I have been discussing 'script preloading' over at the WHATWG list and
> have been pointed to 'lazyload'.
>
> I'd like to try and clarify something that I do not see in the specs, and
> a couple previous points I came across in previous recent threads.
>
> First, Simon Pieters said: "Blink blocks the load event on <script async>.
> Is that a bug? It seems
> someone would've complained by now."
>
> It does not appear to be a bug as long the script started fetching prior,
> as per spec [1] saying:
> "Fetching an external script must delay the load event of the element's
> document until the task that is queued by the networking task source once
> the resource has been fetched (defined above) has been run."
> The spec [3] would need respective updates to section 4.3.1 The script
> element [1], in regard to lazyload.
>
>
> Second, the lazyload spec [3] currently mentions: "If a script element has
> both the defer and lazyload attributes specified, the lazyload attribute
> MUST take precedence".
>
> While that seems to imply that lazyload scripts are further down the
> priority of defer scripts.
> However that does not tell me if a lazyload script is expected to held up
> for, until execution?
>
> As developers we need a clear sensible indication as to when lazyload
> scripts can start executing, in order to be able to actually register
> onload events on them with external scripts.
>
> If you take the execution sequence of the spec [3],  my expectation
> is/would be the following:
>
> 1. readyState.interactive fires
> 2. Execute the "list of scripts that will execute when the document has
> finished parsing".(defer, etc)
> 3. DOMContentLoaded fires
> 4. Execute the "set of scripts that will execute ASAP".
> 5. readyState.complete fires
> 6. Start executing lazyload scripts ASAP
> 7. window.load (not held by lazyload elements)
>
> I don't see a major issue with the assumption put forth by Jatinder:
> "However, this does mean developers will need to register an onload handler
> for lazyload elements that they're interested in tracking. Is this a
> reasonable expectation?" [4]
>
> As long as I know, at which stage lazyload scripts are meant to be
> executed. Without such requirement any lazyload script could execute before
> a 'defer' script, which would not be a reasonable expectation.
> This would also mean a necessary revision of "8.2.6 The end" [3] with
> a specified priority given to 'lazyload'.
> i.e. lazyload scripts should NOT be considered "scripts that will execute
> ASAP" especially not at 'interactive'.
>
> I propose it to be after 'complete' to clearly indicate that 'lazyload' is
> post-DOMReady (or as generally assumed as DOMReady). Perhaps the download
> for all other lazyload element should not start before 'complete' either,
> or a least not before DOMContentLoaded fires, to allow the removal of
> lazyload elements via events handlers on 'interactive' (when the DOM can be
> fully manipulated).
>
>
> Finally I would just like to suggest calling it 'delay' which is slightly
> shorter than 'lazyload' and perhaps less of a technical geeky term…
>
> Bruno
>
> [1]
> http://www.w3.org/html/wg/drafts/html/master/scripting-1.html#restrictions-for-contents-of-script-elements
> [2] http://www.w3.org/TR/2011/WD-html5-20110525/the-end.html#the-end
> [3]
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html
> [4] http://lists.w3.org/Archives/Public/public-web-perf/2013Jun/0026.html
>