[Bug 12049] New: Script defer/async attributed have no realistic usage scenario

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

           Summary: Script defer/async attributed have no realistic usage
                    scenario
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: silvio.ventres@gmail.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


The point of defer'ing or async'ing a script is to allow other content to load
without blocking waiting for the subject script to load.
But the information regarding which script load will be slowest is not
available at time of web page authoring, especially if scripts are not hosted
at the same server as the webpage itself.

The effect is that if a web developer wants to make the web page "faster" and
more interactive, seen especially in lower initial paint latency, he should use
defer/async wherever possible. Given that the dependency tracking between
scripts is not an easy problem for an average user to solve, and that, while
testing with local/unloaded hosting facilities, the low latencies will mask any
dependency problems, the user does not have an easy way to determine if some
script would be hurt by deferring or even asyncing it. This leads to use of
defer/async everywhere, which might break the page layout when some performance
problem with hosting of any resource arises.

Thus, propose to add into the standard that the only attribute regarding
execution order to be user-specified should be "strict" or "strict-order". In
all other cases, browser should do the guesswork determining which scripts can
be deferred, and tracking dependencies, deferring slow-loading scripts,
especially if hosted in different domain-origin. If the slow-loading script
should ever finish loading, the browser should then examine the script and
determine whether the whole page should be reparsed.

This will allow the browser to provide low-latency initial paints for all
webpages, except those that explicitly specify the "strict-order" attribute,
knowing full well the performance impact of such change.

Make the mostly-clueless majority of modern web developers default to "fast and
corrected automagically" and the clueful minority able to choose "possibly
slower and overriding the automagic" if they wish to. Otherwise you risk the
mostly-clueless majority to default to "fast and incorrect" which
browser-developers will then have to add quirks to mitigate.

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

Received on Saturday, 12 February 2011 21:44:45 UTC