[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 #5 from Kyle Simpson <w3c@getify.myspamkiller.com> 2011-08-30 14:22:27 UTC ---
> I think we should support readystatechange events for scripts in an
IE-compatible way.

I very much support this being done. There's a proposal to WHATWG to do exactly
that.

However, in the interest of making sure we're all on the same page, there's a
very important nuance there that you may or may not be aware of/intending,
which in its ommission would be quite a bad thing.

To say "let's support `readystatechange` like IE does" would also need to mean
that you support IE's current behavior of "preloading" a script as soon as the
`src` attribute is set on an element, but not executing the script until that
element has been appended to a DOM.

Why? Because part of what IE does with the "readystatechange" event is to start
off `readyState` at value "uninitialized". Then when the script finishes
*loading* only (NOT when it finishes executing, which is the `onload` event),
it fires for `readyState==loaded` (or "complete" depending on if it was from
cache or not). If the script element is not attached to a DOM at that point,
this event fires to let you know the script finished loading, but didn't
execute.

That behavior is precisely the behavior relied upon in LABjs in IE for
"preloading", because it allows many scripts to be loaded in parallel, but
their execution order be controlled by what order they are added to the DOM,
once they are finished loading.

The proposal I put forth to WHATWG was to standardize this behavior from IE:

http://wiki.whatwg.org/wiki/Script_Execution_Control#Proposal_2_.28Kyle_Simpson.29

In fact, the spec already mentions the "preloading" behavior I described as a
performance suggestion. The spec does not currently mention the
`onreadystatechange` event behavior, which is CRITICAL to making a preloading
mechanism work, but that's exactly what my proposal says should happen.

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

To be clear, if any browser implements `onreadystatechange` and `readyState` on
script elements, AND they start it out initially at value "uninitialized" as IE
does, but they don't do the above "preloading" behavior, then that WILL break
current versions of LABjs (2.0+), because LABjs tests for this and uses it
(obviously currently only in IE).

The reason it's not broken in Opera is because Opera doesn't start out the
value at "uninitialized" like IE does. So, the feature-test in LABjs looks not
only for the `readyState` property on a script element, but also for its value
being "uninitialized". I've had several Opera devs promise that they would
never change there default value to "uninitialized" unless they were also
copying the "preloading" behavior, so at the moment, the feature-test as
described is safe.

Bottom line: I fully support, and have proposed, that script elements be
standardized to behave like they do in IE with regards to `readyState`. But
that also critically means that they behave fully (not just partially) the
same, meaning that they do the useful "preloading" behavior too. Going half-way
on that would very much break LABjs, and thus any of the many sites using it.

-- 
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 Tuesday, 30 August 2011 14:22:34 UTC