[whatwg] Link.onload; defer on style, depends

Tue Apr 28 00:06:24 PDT 2009

Ian Hickson wrote:
> As far as I can tell, as specced, there isn't a race condition (other 
> than the inherent network race condition).
> 
> http://www.whatwg.org/specs/web-apps/current-work/#delay-the-load-event
> 
> In this case:
> 
>    <body onload="2">
>     <img onload="1; image = new Image(); image.src = 'test'; image.onload = 3">
> 
> The main 'load' event is queued as soon as there is nothing left that 
> depends on it -- which happens as soon as the <img> load event was queued 
> up, but before it runs. So the handlers run in the order given (1, 2, 3).

The testcase I was thinking of is:

   <body onload="3">
     <img onload="1; image = new Image(); image.src = 'test'; 
image.onload = 2" src="foo">
     <img src="bar">

In Gecko, on this testcase, the handlers always run in the order 1, 2, 3.

In your spec, if I understand it correctly, they can run in the order 1, 
2, 3, or they can run in the order 1, 3, 2, depending on the order in 
which foo and bar load (and even more precisely, the order in which bar 
loads and the load event for foo runs).  While this is pretty similar to 
the inherent network race condition (you have no way to predict whether 
the load for foo or bar will complete first), it's not quite the same. 
In particular, in this case there is a simple manner of eliminating the 
race without very much sacrifice (e.g. without having to serialize 
network requests or anything silly like that).

Again, I think there are pros and cons to both approaches; it's not 
clear to me how big a deal the race above is, and it's not clear to me 
what the benefits of not waiting for the "test" load before firing 
onload are.  But it's also not clear to me what the benefits of waiting 
for it would be.  Gecko's behavior is largely a result of the load event 
firing sync and the need to have it fire after image load events.  It's 
just not black-box-equivalent to what you currently have specced; that's 
all I was saying.

-Boris