[whatwg] readystatechange for SCRIPT

>> So, can I clarify something? You have moved `onreadystatechange` and
>> `readyState` off of the <script> element entirely, and onto the HTML
>> element?
>
> No.  They've been removed from elements (and windows) entirely.  They
> remain on Document.

So, if I understand correctly, you've simply said there will be no 
`readyState` property progression for script elements?


>> In regards to all the concern about double-firing of load detection
>> logic, IE9 added both `onload` event firing to their existing script
>> element's `onreadystatechange` firing.
>
> In all modes?

IE9 in standards mode fires both events. Check the test I posted earlier in 
the thread:

http://test.getify.com/test-script-onload-and-readystate.html


>> So, I'm not sure why we're rushing to fear these problems. A few years
>> ago, maybe this was an issue, but I don't see how there's real evidence
>> of current problems. Most script loaders are already immune to this
>> problem.
>
> Opera pointed to a specific script loader in the Facebook API that is
> not thus immune, as well as one in popcornjs.
>
> Given an existence proof like that, "most" doesn't really cut it for me,
> unfortunately.

Those faulty script loaders may indeed exist. My point is, they are already 
broken (or at least susceptible to breakage) in IE9 standards mode and in 
Opera, both of which fire both events for script elements. Given the fact 
that those script loaders are already broken before we even consider what we 
do with the spec or in other browsers, *they* are clearly faulty and should 
be fixed, not used as an indirect excuse to "throw the baby out with the 
bathwater". Their breakage is orthagonal to this discussion because it 
predates this discussion, and it's neither helped nor harmed by either 
outcome of this thread's proposal.

Completely undoing/removing `readyState` from script elements doesn't 
actually do anything to address the existing fact that any script loaders 
(such as those cited) which are not paying attention to the fact both 
`onload` and `onreadystatechange` fire for a script element in 2 of the 5 
major browsers is a broken and faulty loader.

Those script loaders should be fixed regardless of what is decided in this 
thread -- that much should be clear. So if they are fixed, then they're a 
moot argument against considering a simple `readyState` mechanism for script 
elements.


> Or put another way, I would not be willing to implement readyState on
> scripts in in Gecko as things stand, without a lot stronger data
> supporting the fact that scripts no longer listen for both load and
> readystatechange.

I think that's an improper standard. What should be asked is: will the 
proposed change break any existing scripts in new or worse ways than they 
already are? The answer is no. And OTOH, will it help some scripts? 
Apparently, yes (yandex).


--Kyle

Received on Saturday, 10 September 2011 20:20:41 UTC