[whatwg] Script preloading

[Kyle Simpson]

>> But I'd settle for anything, no matter how complex, as long as it actually solves the many use cases. Your proposed option has potential, as long as the missing "event" part is addressed.
> 
> It seems to me that from an IE-perspective, the only missing piece is the event itself.

Well, strictly speaking, IE4-10 had a suitable event already, as you surely know. Unfortunately, IE11 has, currently, removed those event handlings, as they are "non-standard". I wrote this blog post a few days ago "begging" the IE11 team to bring them back:

http://blog.getify.com/ie11-please-bring-real-script-preloading-back/

I know it was passed on to at least a few of the decision makers there, but I've not heard anything official in response yet. Any update? :) As it stands, the IE version of "real preloading" is in limbo and in danger of dying, as it's quite neutered without some event.

IF we could act quickly enough to standardize some preloading approach, even if that were different than how IE did it before, *maybe* it could make it into IE11 before final release? I dunno.



>> Just one final side note on the above linked-to proposals (Zakas's and mine). Over 2 years ago, I implemented feature-detects in LABjs script loader for both of those proposals. Of course, the `readyState` one actually works in IE4-10 and works beautifully I might add. In head-to-head loading tests I've done from time to time, the IE "real preloading" mechanism often beats out the good-but-not-great "ordered async" of the other modern browsers.
>> The `preload` one doesn't currently work of course (it's just dormant code for now), but I thought it to be a sufficiently good enough proposal, and likely enough to eventually happen, that I put in those few lines of code to LABjs, as speculative future-proofing.
> 
> The LABjs source code uses a feature-detect for the "real preloading" by looking for the existence of the "preload" Boolean DOM attribute. After thinking about it for a bit, I'm not sure I understand why that attribute is necessary. 

I believe the reason that Nicholas suggested that the attribute needed to be there was two-fold:

1) he was concerned about the "implicit" nature of IE's behavior by sort of indirectly preloading simply by developer non-action (not inserting into the DOM).

Adding a positive attribute to a tag to say "yes, I want this preload-and-defer-execution behavior" was certainly more explicit, and opt-in, and thus maybe more attractive, since it had perhaps less potential to create accidental problems for legacy content or developer ignorance.

2) it makes for a simple/effective feature-detect. :)


Whatever mechanism we do have, we need a feature detect for it, obviously. `"preload" in document.createElement("script")` is nice and clean and semantic.

The "IE way", I detect by looking at the readyState and noticing its initial value, which was an IE only behavior. Opera was the only other browser to support `script.readyState` (but NOT support the actual preloading concept), but Opera's version of the property has a different initial value.

I asked an Opera developer specifically and he asserted that Opera would not ever have an occasion to change that initial value to the same as IE's unless they were also matching IE's preloading behavior. Thus, we avoided (tenuously, in the absence of standards) any false-positives on that feature detect.



> If I were to only introduce the event handler (onpreload) it seems to address the use cases, but then your 2+ year old dormant code would stay dormant :( 

I'm not nearly as concerned about dormant code staying dormant "forever". I made the judgement call back then that the extra ~100 gzip-bytes were "worth it" if a future day ever came that it just magically worked.

I'd love it, for LABjs' sake, if whatever was standardized was one of the two approaches, either one.

But even if we standardized a third option, and I had to change LABjs, that would be FAR BETTER in my mind than never addressing this use case at all, especially in light of IE11 sort of retreating on this topic (either intentionally or not).





--Kyle