- From: <bugzilla@jessica.w3.org>
- Date: Wed, 23 Feb 2011 20:03:40 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12049 --- 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 evokation. 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 standard. 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