[whatwg] readystatechange for SCRIPT

[Boris Zbarsky]

On 9/10/11 11:20 PM, Kyle Simpson wrote:
>>> 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?

As of the last spec revision, there is no readyState property on script 
elements, no onreadystatechange property on script elements, and no 
readystatechange events fired on script elements.

>> In all modes?
>
> IE9 in standards mode fires both events.

Well, sure.  I was specifically asking about the _other_ modes.  In 
general, the argument that behavior X is web-compatible because IE has 
it falls down if IE only has behavior X in standards mode.

> Check the test I posted earlier
> in the thread:
>
> http://test.getify.com/test-script-onload-and-readystate.html

On this test, I only see the event fire in IE9 Standards Mode.

In other words, I don't think that Microsoft shipping this means that 
people have stopped using the sort of script that caused problems for 
Opera.  At best it means they either stopped using it or switched the 
relevant pages to one of the IE compat modes, since that's so simple to 
do... or that Microsoft itself put them on its compat mode list during 
testing.

> Those faulty script loaders may indeed exist. My point is, they are
> already broken (or at least susceptible to breakage) in IE9 standards
> mode

Which they may well not be running in; see above.

> and in Opera

Which they clearly don't care about, right?

What makes you think they would start caring any more if they were 
broken in some other browsers?  What's the incentive for browsers to 
thus break sites?

> 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

Sure, they're faulty.  So what?

> and should be fixed

Yes, and we should all have ponies if we want them.

The web doesn't work like that, sorry.  :( Would be nice if it did!

> Their breakage is orthagonal to
> this discussion because it predates this discussion,

Their breakage is making the only UA other than IE that implements 
onreadystatechange on <script> plan on removing that support.  That 
seems to be pretty relevant to the discussion of whether the spec should 
require onreadystatechange on <script>.  If UAs are not going to 
implement it (and a UA _removing_ it is pretty good evidence they're 
not, imo), then the spec requiring it is silly.

> 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.

This is not the relevant fact.

The relevant fact is that such loaders exist, are most likely broken 
only in Opera for now, but would break in Gecko and WebKit if those were 
to implement onreadystatechange on <script>.  Their existence thus 
likely precludes Gecko and WebKit implementing it.

> Those script loaders should be fixed regardless of what is decided in
> this thread -- that much should be clear.

Great.  Do you have time for that?  Does anyone else?  Will the site 
owners even respond?

My experiences with getting web pages to fix their scripts are not very 
positive... maybe yours are different.

> So if they are fixed, then
> they're a moot argument against considering a simple `readyState`
> mechanism for script elements.

If they're fixed, and we have good evidence of that, then we can revisit 
this discussion, absolutely.

>> 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.

I think it's the only relevant standard here: will implementing this 
break websites for my users?  If it will, why would I implement it? 
Maybe there are good reasons, but they'd better be pretty overwhelmingly 
good.  I'm not seeing such reasons here.

If the concern is just to have a readyState-like setup available on 
<script>, that could still be done, just using a different event name 
that hasn't been poisoned yet.

> What should be asked is: will the
> proposed change break any existing scripts in new or worse ways than
> they already are?

Sure, for users of all browsers other than Opera.

I think you're completely misunderstanding the relevant meaning of 
"break" here.  It's not "is the script broken?" it's "is the page broken 
when a user loads it?".

I would venture to say that the vast majority of scripts on the web are 
"broken" by your metric.  100% of the ones doing UA sniffing are.  But 
it all ends up working out in practice, sort of.... By your reasoning, 
any change that breaks any script that does UA sniffing in any way is 
OK.  I realize that's an extreme version of your argument, but that's 
what you argument is, on a slightly smaller scale in terms of (user, 
website) pairs impacted.

> The answer is no.

See above.

> And OTOH, will it help some scripts?
> Apparently, yes (yandex).

If we can help yandex without breaking other sites in the process, that 
seems better than helping yandex while breaking other sites, all else 
being equal.

In this case, all else is not quite equal, but I don't see good evidence 
that the site breakage Opera has been dealing with is worth the dubious 
benefits of standardizing the onreadystatechange behavior on <script>.

Again, I see no problem with possibly standardizing something on 
<script> that gives equivalent functionality using a different event name.

-Boris