[whatwg] Link.onload; defer on style, depends
bzbarsky at MIT.EDU
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).
> 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:
<img onload="1; image = new Image(); image.src = 'test';
image.onload = 2" src="foo">
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.
More information about the whatwg