[Bug 14194] New: Request: specification for script preloading

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14194

           Summary: Request: specification for script preloading
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: w3c@getify.myspamkiller.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


There's been much discussion, both on and off list, about the use-cases for
script preloading. In particular, several proposals were formalized here:

http://wiki.whatwg.org/wiki/Script_Execution_Control

After speaking with several developers at Mozilla to come to some agreement, we
would like to ask that a mechanism for script preloading be specified.

To be clear, what we're asking for is a mechanism by which:

1. from JavaScript code, one or more external JavaScript file(s) can be
requested to download, but the user agent will *not* execute them automatically
upon load completion.

2. Scripts being preloaded must be loaded in parallel in a separate queue (so
as not to block or be blocked by) the queues used for `defer`, `async`,
"ordered async", etc.

3. The user agent needs to fire an event for each script element which
indicates that the script has finished loading (but not executed). This event
must fire even if the script element is already in the cache and preloading is
moot.

4. The user agent must allow a script that has finished loading (been
"preloaded") to be executed synchronously.

The suggestion would be to take one of the two main proposals listed in the URL
above as the starting point for such a mechanism.

--------------

Discussion:

One of the most valid concerns that some user agents have expressed about such
a mechanism revolves around *my* proposal, which is to standardize IE's
"implicit preloading". Implicit preloading carries with it a potential "risk"
of abuse or misuse by developers whereby many scripts could be preloaded (kept
in memory) but never used, thus wasting precious bandwidth and memory
(especially on mobile devices). This concern mainly arises because implicit
preloading could happen without the author even knowing or expressing intent to
do so.

The alternate proposal detailed in the above link (from Nicholas Zakas) was for
"explicit preloading", which would not activate preloading for a requested
script unless the web author specifically sets a "preload" flag on the element.
Explicit preloading reduces the chances that a web author can accidentally
misuse the mechanism with unintended waste of resources.

OTOH, the implicit loading mechanism proposal is fully compat with IE (since
v4), which is attractive for web authors because it means compat instead of
browser feature-forking.

A recent discussion thread expressed great concern about of "double-fire"
issues (in Opera and IE9 standards mode) with web authors *incorrectly*
listening for both the `onload` and the `onreadystatechange` events but not
filtering that both events will fire for a script element. While this is
clearly web authors behaving incorrectly (conflating the two event handlers),
the concerns are great enough that it was felt that `onreadystatechange` could
*not* be added to script elements (as IE has).

So, if the "implicit preloading" proposal were to be considered, the people I
spoke with at Mozilla feel that the event name would have to minimally be
different than `onreadystatechange`, to break with that existing web content
bugginess. For instance, near-complete compat with IE's preloading behavior
could be achieved by taking all other parts of the proposal the same, but
changing the event name to `onreadystate` (dropping "change"). While not
perfectly ideal in terms of compat, this wouldn't be too onerous for script
loader authors to feature detect the appropriate event name to listen for.

On the whole, I probably now lean toward suggesting "explicit preloading" like
Zakas' proposal has. This is unfortunate for non-compat, but it addresses
several of those arguments above in a clean'ish way.

The developers I spoke with at Mozilla feel there is merit to script
preloading, but they want the spec to define a mechanism for it before they
implement it. Their only concern was that the specification not be so limiting
so as to prevent the user agent from having some leeway in how such a mechanism
is actually implemented/managed.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 17 September 2011 19:59:51 UTC