W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > February 2011

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 23 Feb 2011 20:03:40 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PsKw0-0003oA-Lt@jessica.w3.org>

--- Comment #5 from silvio.ventres@gmail.com 2011-02-23 20:03:39 UTC ---
After giving the idea some more thought, it became apparent that there is a
solution to the script dependency tracking.

It's quite simple, really.

Again, assuming most users don't have a clue regarding script order, and don't
really have any means to do it correctly,
especially with scripts that are externally-sourced and thus have dynamic
loading performance, the solution is to assume
all scripts are deferrable, unless they depend on a non-defined function

The engine should execute scripts as they arrive from the network, in whatever
random order that is, until an undefined 
function call is encountered. At that point the scenarios can be different.
Here are two:

First scenario:
  The browser engine saves a snapshot of the DOM before script initial run.
After encountering the undefined function,
the changes are rolled back and the script is pushed to the end of the
"deferred" queue, and flagged so it can only be
executed after at least one different script is executed. In case the queue is
empty, the function is really considered
undefined and an error exception is triggered.

First scenario Optimization:
  The undefined function/functions are saved in an "undefined_functions"
hash/table and the script retried execution only
when all functions have been provided definitions or there are no more scripts
to run.

Second scenario:
  The browser engine launches script execution in a separate sleep-able thread.
After encountering the undefined function
the engine puts the executing script to sleep and sets its wake time as in
first scenario - either executing after another
script or when the function symbols have been resolved.

Whether it's easier to do DOM snapshots, analysis and rollbacks (with alert()
workarounds) or multithread sleep/wake is left to the browser developers to
choose. Additional implementation-specific solutions might exist too.

This provides ability for the web browser to "process" and provide the user an
output given "incomplete" data.
Given that most of the time this "incomplete" data are externally-sourced ad or
tracker scripts, this solution should
solve the problem.

For comparison, on technorati.com and other alexa-2000 sites setting
external-source scripts to defer unconditionally
halves the first-paint time on WebKit implementation without causing any bad
renders. Although that has theoretical
problems, the above algorithm should be 100% compliant with the current

Thus, advise to use the above algorithm and move the script deferability
decision from webdev to the browser, where it belongs.

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 Wednesday, 23 February 2011 20:03:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC