[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 #10 from Kyle Simpson <w3c@getify.myspamkiller.com> 2011-09-03 12:58:13 UTC ---
(In reply to comment #7)

> Would having <script> elements have a readyState IDL attribute that has the
> following states, and for which an event gets queued whenever the value
> changes, be ok?
> 
>  'uninitialized' - script file isn't loaded (or specified) yet, but UA is going
> to preload it ASAP (after the "src" is set if it's not already set).

Does this mean that a UA like Firefox (which seems unwilling to do preloading)
would *not* start in "uninitialized"?

Let me reiterate from my previous comments... if you have a new freshly created
dynamic script element with a readyState==="uninitialized" (like IE does), but
that UA is *not* going to do preloading, then that WILL break LABjs badly.

In other words, a UA that doesn't do preloading must specifically be forbidden
to start out with this value.


>  'loaded' - script file is loaded, or, script file isn't loaded but UA isn't
> going to preload it anyway so it doesn't matter.

This would only be acceptable for LABjs (that is, not break it) if UA's that do
not support "preloading" never have the previous "uninitialized" value. I think
that's what you're implying here, but I just want to clarify that's in fact a
true statement.

LABjs never tries to use `readyState` preloading if the initial value is not
"uninitialized"... so that's the locked door entrance for this behavior, that
needs to either unlock if there's preloading, or stay locked if there's not. If
that's true, then any other progression of the values is irrelevant to LABjs
because it won't inspect or use them.


> I believe this would allow both for the IE preload behaviour and for the
> non-preload behaviour, and would be compatible with yandex and LABjs. 

With the clarification of "uninitialized" above, it won't break LABjs.


-----------------------------
> (We want
> to allow preload to be optional since it should, in theory, be just a
> performance issue, and some UAs may prefer to err on the side of low bandwidth
> usage rather than on the side of fast script execution.)

We've had lengthy discussions about active intentional preloading, and there
are literally more than a dozen arguments that I've provided as use-cases for
why preloading is necessary for the web. I strongly object to the implication
that it's a side optional issue that should be left unspec'd.

Would it help if I collected "signatures" on a petition to show you how much
value and interest there is in some sort of official "preloading" mechanism
(sans hacks)?

If your only concern is that some UA's (in low-bandwidth scenarios) would
*potentially* (and I stress potentially, because they might not) load scripts
too early if they start fetching on setting of the `src` property (in other
words, how IE has done it since v4), then at least consider the first proposal
from Nicholas Zakas, which makes preloading an *explicit* thing rather than an
implicit thing.

Surely you can see that if an author (such as me, of LABjs) decides to opt for
*explicit* preloading, then that author is doing it on purpose, with a specific
intention to use the scripts in a specific way (not an accident of implicit
preloading), and he has thus said that script loading is the most important
thing to enable/preserve. He's furthermore saying, by opting into explicit
preloading, that the UA should in fact load-but-not-execute the scripts in
question, because the author of the script loader intends to decide (later) in
what order they execute.

Explicit preloading under Zakas' proposal would be a fair balance between the
fears of bandwidth-wasting in implicit preloading (my proposal) and no direct
preloading at all, which continues to plague the land of script loaders with
all manner of horrible hackiness, like the awful "cache preloading" that is so
brittle and inefficient.

-- 
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 Saturday, 3 September 2011 12:58:16 UTC