W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > September 2011

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

From: <bugzilla@jessica.w3.org>
Date: Mon, 05 Sep 2011 12:51:32 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1R0YeC-0008NL-Uj@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13965

--- Comment #16 from Kyle Simpson <w3c@getify.myspamkiller.com> 2011-09-05 12:51:26 UTC ---
(In reply to comment #15)
> Per comment 1, any UA which has an "onreadystatechange" property on <script>
> must also at some point fire a "readystatechange" event at a point when
> .readyState returns either "loaded" or "complete".  Not doing that breaks at
> least Yandex.
> 
> It's not clear to me that your last proposal has this property.

OK, fair enough. I ammend my proposal to exclude the "unsupported" case.

To restate, then, I propose that `readyState` start out at "unloaded", and at a
minimum move from "unloaded" to "loaded" with a single `onreadystatechange`
firing. This firing should happen *before* `onload`. 

Why? Because IE fires "loaded" (or "complete") even if it has not executed the
script (only downloaded it, for preloading), whereas `onload` always comes
strictly after the script is executed.

Additionally, since IE has always started out at "uninitialized", we should
allow that initial value as well, so `readyState` can either start out as
"uninitialized" or "unloaded".

To prevent breakage of LABjs, if the initial value is "uninitialized" (like
IE), then the UA must support preloading (like IE). If the initial value is
"unloaded", the UA must not support preloading.

This lets UA's choose to do a full `readyState` progression mechanism, which
implies preloading (like IE), or just a simpler `readyState` mechanism which
only fires once, from "unloaded" -> "loaded".

My proposal would strictly make Opera's current implementation non-conforming,
but I think that's a good thing because I think it's quite non-sane/confusing
how they artificially fire the event even if the value doesn't actually change.
I think they'd probably admit it's non-ideal as well.

The saving grace is, it's non-conforming for Opera in non-breaking way, in that
current/past Opera's will continue to artificially fire once for "loaded", and
them later changing their initial value to "unloaded" to achieve spec
conformance shouldn't be a breaking change for them or any web content.

-------------------

Yandex's current feature test seems to just be if `readyState` property is
present. IMHO, this is a poor feature test, and should be changed. However,
even if they don't change, my proposal should preserve their functioning.

For IE prior to v9, they didn't support `onload`, so `onreadystatechange` was
the only option. It makes complete sense why scripts would rely on it in IE.

This was never true for Opera though (at least not in recallable memory). They
always had the (seemingly) more preferable `onload` support. So I'm not sure
why any script would prefer to rely on `onreadystatechange` in Opera (as
non-sane as it is) in favor of the more reliable and semantically sensible
`onload`.

As such, I would advise that Yandex should consider changing their feature test
for relying on `readyState` to be:

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

That *would* cause them to stop using `readyState` in current Opera, but if
Opera eventually "fixes" their behavior to start out at "unloaded" (or
"uninitialized" if they decide to support preloading), then it'd be available
to Yandex again.

-- 
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 Monday, 5 September 2011 12:51:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:18 UTC