[whatwg] readystatechange for SCRIPT
bzbarsky at MIT.EDU
Sat Sep 10 20:40:29 PDT 2011
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
>> 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:
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
> Those faulty script loaders may indeed exist. My point is, they are
> already broken (or at least susceptible to breakage) in IE9 standards
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
> 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.
> 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
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.
More information about the whatwg