- From: <bugzilla@jessica.w3.org>
- Date: Sat, 08 Jan 2011 07:09:38 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 --- Comment #15 from Kyle Simpson <w3c@getify.myspamkiller.com> 2011-01-08 07:09:37 UTC --- (in reply to comment #14) I still strongly feel the proposal for the symmetry of "async=false" has value in most of the use-cases surrounding script loading. I am very glad and thankful that Ian has considered spec'ing the simple proposal. The majority of sites do NOT have such a complex dependency graph of multiple independent trees of dependencies, in which the single "global queue" you refer to would become any kind of a bottleneck or hindrance. That's not to say that type of use-case is invalid. Sites like that certainly exist, and there's value to a mechanism that could address that use-case, very well perhaps using the "preloading" mechanism you referred to, which is currently specified as a "may" option for browser vendors (in step 12 of the script loading algorithm). In fact, if combined with something like `readyState` monitoring (like IE's implementation does), there's a very valuable set of advanced use-cases for loading scripts but deferring (some or all of) their execution until much later. This is functionality we should definitely ask browser vendors to implement (as it's already suggested in the spec). Granted, the "preloading" mechanism IS functionality that would not only fully serve, but also exceed, the capabilities of the currently discussed "async=false" proposal. HOWEVER, I think it's a mistake to conflate these two different sets of functionality into one discussion, or to suggest that one precludes the utility of the other. I think they're separate, and should be kept that way, and that each of them has independent merit. The value to the currently discussed "async=false", on top of the consistency/symmetry argument (which is strong in and of itself), is that it serves a pretty sizeable chunk of the web's current needs for script loading, and does so in a way that is very simple and straightforward for script loaders to utilize. If say 80% of all sites' script loading needs can be well-served by "async=false" (a relatively simple change for most browsers), then I think it has value (instead of a more complex system that might also work). In a separate (but certainly useful) effort, I think the more advanced 20% use-cases (more complex dependency trees) can and should be pushed via the other "preloading" mechanism (aka, load-but-don't-execute). However, *that* discussion doesn't really belong here (since the spec already mentions both its method and value), but rather with browser vendors directly. -- 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, 8 January 2011 07:09:39 UTC