[Webkit-unassigned] [Bug 50115] Please implement async=false for dynamic script loading (REGRESSION: LABjs is broken)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=50115





--- Comment #39 from Kyle Simpson <getify at gmail.com>  2010-12-29 10:37:54 PST ---
@Alexey--

With all due respect, I believe the opposite. The discussoin with WHATWG and the W3C members has been going for quite awhile. Some people support the proposal, others don't. This is true of any proposal, no matter how small or how big.

I think what's needed is browsers to *agree* to implement something, so it can be tried out (and proven/disproven) in the real world. Mozilla has done so. Opera is potentially considering it. And thus far in this discussion thread, Webkit is attempting to do so. If we have 2 or 3 major browsers agreeing on a feature, and it works, there's a good chance the others will come around, and the spec will eventually codify it.

-----------
There've been lots of other possible alternatives talked about (including <scriptgroup>, "depends", etc), but ALL of them are more complicated and have a wider surface-area of spec and browser functionality change. And many of them are not suitable to the main use-case.

To be clear, "async=false" as a proposal is not completely what I would want eventually from all browsers. There's another mechanism, already as a "may" suggestion in spec, that I would much prefer. But only IE implements it now, and the spec under-defines it only as a suggestion thus far. This is much further away from being a viable solution. So "async=false" is the next best thing, and certainly has a smaller surface-area of change and potential breakage.

*Right now*, at this moment, Webkit nightlies (by following the letter of the law in spec) have broken a hugely important use-case, and a bunch of sites that use script loaders like LABjs that rely on that use-case.

Just like when Mozilla's change broke LABjs back in October, and then they implemented the "async=false" proposal as a stop-gap to prevent existing content from breaking, I'm requesting that Webkit do the same, so that a browser like Safari or Chrome do not release with a trunk of Webkit that breaks the sites and the use-case.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.