[whatwg] Link.onload

Garrett Smith dhtmlkitchen at gmail.com
Sat Mar 14 18:18:43 PDT 2009

On Sat, Mar 14, 2009 at 5:24 PM, Greg Houston <gregory.houston at gmail.com> wrote:
> On Sat, Mar 14, 2009 at 4:46 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
>> I proposed a solution to a similar problem not too long ago.
>> <script depends="[idref]" ...></script>
> For me to implement my own "depends" lazy loader without any hacks the
> only thing missing is that link onload callback.
> Given the following example, with depends, if a, b, or c are links,
> how would you set their "title", "rel", "href", "media" and other
> attributes? If a, b, or c is a script, how would you set the "id" or
> "type" of that script?

The proposal is to add the id in the markup, using the ID existing attribute:-

<link rel="stylesheet" href="a.css" title="a styles" media="screen" id="a">
- and -
<script id="b" src="b.js"></script>

> <script depends="a b c"></script>

Waits for a and b to load and:-

<script depends=""></script>

waits for nothing.

>><link onload="loadPlayer()" ...>
> This is sort of what I am doing, but missing a couple steps:
> This is basic usage:
> [The following examples are using Mootools syntax]

I understand you are using Mootools. The syntax is ECMA-compliant (in
this case).

That, and the example seems to add more complexity than necessary to
provide sufficient explanation (IMO, a simpler example is preferable).

The method chaining and Mootools' misguided augmentation of Host
object (document.head here) makes the code less clear. The reader
should not be forced to understand details about Mootools to
understand your example.

[snip code]

> I think a native lazy loader such as something along the lines of your
> depends is a great idea. It would obviously have to be much simpler
> than what I am doing, sort of in the same vein that you can use the
> HTML 5 meter or create your own and have more control. I think your
> idea would probably need more fleshing out though and would require a
> great deal more from the user agents than what I am requesting, which
> again is just an onload callback from the link element.

It would require more support from implementors than what I have
gotten, that is for sure.

Link.onload is simpler for implementors. We have at least two browsers
(opera, IE) that support that already.

OTOH, depends="" offers declarative style for automatic resolution of
dependencies. Though more complex than link onload, depends="" would
seem to be cleanly implementable (though slightly more complex) via
internal events. If depends="" were implemented, what would be the
use-case for link onload?

> On a side note, I can actually attach a functioning onload event to a
> link element in Internet Explorer. Firefox, Safari, and Chrome ignore
> my attempt, and Opera will fire the onload event but not update the
> style of the page. Opera gives the most curious result. I didn't

You got a result (in Opera, using Mootools). It should be explainable.
Possibly you have invalid css syntax that opera rejects (check your
error console).

> actually check the DOM to see if Opera appended the stylesheet or not.
> It may be that it just short circuits and fires the onload event.

Opera will fire the onload event when the stylesheet load fails.

[snip example]

Mootools provides a layer of abstration that gets in the way of making
your case. It seems more prudent to use the actual syntax you desire,
sans the "Mootools" abstraction layer.

<html lang="en">
  <title>link onload</title>
<script type="text/javascript">
function addStyleSheet() {
  var l = document.createElement("link");
  l.onload = linkLoaded;
  l.type = "text/css";
  l.rel = "stylesheet";
  l.href = "l.css";
function linkLoaded() {
  document.getElementById('m').firstChild.data = "link onload fired.";
<button onclick="addStyleSheet()">addStyleSheet()</button>
<pre id='m'>link not added</pre>

body {
  background: #3f3;

All browsers updated the document.
Opera, IE7:
  link onload fired.
Mozilla rv:1.9.1b3pre, Webkit 3.1.2, Chrome:
  link not added

> Cheers,
> G.


More information about the whatwg mailing list