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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13965

--- Comment #14 from Kyle Simpson <w3c@getify.myspamkiller.com> 2011-09-04 14:54:40 UTC ---
(In reply to comment #13)
> > but it fires `onreadystatechange` for "loaded" (or "complete") *before* it
> > fires `onload`.
> 
> Interesting.  I tested precisely that in IE9, and I saw the onload firing
> before the onreadystatechange...  Quite curious.

Can you re-run your tests in your IE's with the URL I provided? Which order is
it in? I haven't seen any other order than what I described, but I suppose it's
possible that various race conditions control that.


> > IE fires "complete" instead of "loaded" when the script is purely pulled from
> > cache.
> 
> That's insane.  Par for the course, I guess, but insane.  I don't see a need to
> duplicate this behavior, honestly.  

I'm not entirely sure that you need to, either -- I was just pointing out that
IE's implementation is more complex than was being described, and so should be
considered carefully in any attempt to partially-emulate. But more on that in a
moment.


> For one thing, a UA may have no idea
> whether the script came from cache or not (think intermediate caches, for one
> thing!).
> 
> I fail to see how scripts could possibly depend on whether another script "came
> from cache" (whatever that even means, given intermediate caches).

I have seen code written specifically for IE which loaded a script URL, and if
it seemed to come quickly from cache (both timing wise and this "complete"
state), then a loader wasn't needed, but if not, then a loader icon was
displayed.


> I also fail to see why implementing something like what Opera did would not be
> compatible with the web.

Again, I'm not specifically saying that "like what Opera did" would be wrong to
copy. However, it's more complicated than you say.

Opera basically has a rather non-functional `readyState` implementation on
their script elements. If you run the test in Opera 11.5, you'll see that they
start out the `readyState` variable with "loaded" (*not* firing
`onreadystatechange`) on a new script element, then they fire `onload`
(different order from IE!), then they finally fire `onreadystatechange`, but
with the same value.

*That* seems "insane" to me. They fire `onreadystatechange` when the
`readyState` did not, in fact, strictly change. Why would you want to actually
spec something as insane and counter-intuitive as that?

This is basically a `readyState` system in name-only. There's no progression of
values, so the concept of a "change" event is bogus. And they artificially fire
the event, even without a change, for some unknown reason.

Remember, Opera supports `onload`, so I fail to see any reason at all why Opera
has this non-functional and confusing `readyState` system that works quite
differently from IE's (at least partial attempt at) full `readyState` value
progression and change events.

Moreover, I've had a number of discussions with a few Opera developers, and the
impression I got was that they eventually were considering "fixing" their
`readyState` system so that it behaved more "correctly". Specifically, there
was at least some consideration on their part to do the "preloading" like IE
does, with a full progression of `readyState` values, per my proposal.

Given that Opera's implementation is bogus, and that their contemplating
fixing/replacing it, why on earth would we consider spec'ing that?

--------

My counter-proposal for the spec:

If a UA is going to define and support `readyState` and `onreadystatechange`,
it must at a minimum have one state change, from "unloaded" (or
"uninitialized") to "loaded".

If not, the UA may define a `readyState` variable, but its default value must
be "unsupported", so that developers can properly detect (by inspecting the
default value on a newly created script element) if the mechanism is supported
or not.

The feature test would then be:

var script = document.createElement("script");
var readyStateSupported = script.readyState && (script.readyState == "unloaded"
|| script.readyState == "uninitialized");

For IE, this would pass. For Opera's current implementation, it would not pass.
For any UA's (perhaps Firefox?) newly wishing to have `readyState` "in name
only but not functionality", it would also not pass. For any UA's that intend
to create a working/sane `readyState` mechanism, they do the "unloaded" ->
"loaded" change, firing the event once, and the above test would pass.

That allows a UA like Firefox to either have the property but not use it, OR
have the property and actually use it in a sane way, but in neither case does
that UA *have* to do the preloading that IE does.

This is a compat win.

-- 
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 14:54:44 UTC