[Bug 13965] Exposing onreadystatechange on script elements seems to not be web-compatible unless they fire the event


--- Comment #12 from Kyle Simpson <w3c@getify.myspamkiller.com> 2011-09-04 04:21:07 UTC ---
(In reply to comment #8)

> 1)  We would need an onreadystatechange event right after onload (at least)
>     without the readyState actually changing.

That's incompatible with how IE does it. IE9+ fires both `onload` and
`onreadystatechange`, but it fires `onreadystatechange` for "loaded" (or
"complete") *before* it fires `onload`.


Try that test in IE9 (clear your cache -- *not* just refresh or shift+f5 --
each time you run it) to verify the order of events.

> 2)  I've never seen IE go into "complete" for external scripts in my testing;
>     just for inline scripts (which never go into loaded).

Incorrect. IE fires "complete" instead of "loaded" when the script is purely
pulled from cache.

Again, try out this test, but do so with your cache intact from a previous run
of the page, and you'll see that IE never fires "loading" or "loaded", it only
fires "complete". But it does so strictly before it fires "onload".

(In reply to comment #9)

> Modulo compatibility constraints, I'd say all scripts start in
'uninit'/'loaded' and transition to 'complete' at the same time as 'load',
whether inline or external. It's probably not quite what IE does, even modulo
the preloading stuff, but it seems saner and still compatible with what has
been described so far.

There are definitely scripts on the web which rely on IE's behavior of
"complete" for scripts pulled from cache, and "loaded" for scripts that were
actually loaded.

IE fires one or the other ("loaded" or "complete"), but not both. Firing only
"complete" in all cases will mess up scripts which are looking for "loaded"

And what does "at the same time" actually mean? The order of when they fire (as
shown above) is not clear, and is quite important.

I would strongly caution against spec'ing an incompatible (with IE) set of
behavior around `readyState` on script elements, because they've been around
doing this forever, and there's tons of potential for compat breakage. I would
wager a lot of money that IE will be reluctant to bring their implementation
into alignment with a spec for a different set of behavior or ordering of
events in this area, because of that potential for breakage (lots of sites
still have IE-specific code).

It's a bad idea to spec something and say "Well, IE be damned, we're doing it
anyway", unless there's an overwhelming reason to do so. Saying something is
"saner" is nowhere near that level of overwhelming.

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 Sunday, 4 September 2011 04:21:13 UTC