- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 17 Oct 2010 22:44:03 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public html <public-html@w3.org>
On Sun, Oct 17, 2010 at 10:36 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 10/18/10 1:26 AM, Adam Barth wrote: >> Decoupling the property from the attribute seems undesirable. Maybe >> we should try to address the use case directly rather than trying to >> hack around with the async attribute? Perhaps we should add a >> waitFor="foo bar" attribute to script elements that delays the >> execution of the script until all the scripts with the ids listed in >> the attribute execute (be they defer, async, normal, what-have-you). > > This introduces a fair amount of complexity that needs to be defined (e.g. > at what point do those ID lookups happen, what happens if there are no such > script elements in the DOM, etc). It might be workable, of course; I'd > welcome an unambiguous proposal to evaluate. My first thought would be to keep a list of the ids of all scripts executed by the document (adding the ID of each script immediately before executing the scripts). When you think you might want to execute a waitFor script, you first check this list to see if the prerequisites have executed. If so, then you execute. If not, you append it to a list of scripts-waiting-for-prerequisites. Whenever you add an ID to the scripts-waiting-for-prerequisites list, you check to see if you can now execute any of the scripts in the scripts-waiting-for-prerequisites list. If so, you execute the scripts with fulfilled prerequisites in list-order. (There are some details about insertion points which would need to be nailed down, but you get the idea.) >> That would also have the advantage of being useable declaratively. > > Presumably in combination with @async? Yes. Maybe it would be useful for waitFor to imply async? Adam
Received on Monday, 18 October 2010 05:45:10 UTC