- From: Mike Wilson <mikewse@hotmail.com>
- Date: Fri, 14 Dec 2012 23:28:50 +0100
- To: "'Ian Hickson'" <ian@hixie.ch>
- Cc: whatwg@whatwg.org
Ian Hickson wrote on 14 december 2012 21:11: > > As a general rule, the intent of the spec is that you > get a "load" when all your scripts (and other resources) > have loaded, and you get an "unload" when the page is > going away. Thus if the page goes away before the page > has finished loading, you just get an "unload". Yes, when I think about this a bit more it makes a lot of sense. Initially I did expect a behaviour more like abort/stop - skipping all outstanding i/o and "fast- forwarding" to the firing of the load event(s). But as you say, as we are leaving the page anyway, there shouldn't be a big need to do page load initializations. And a smart page can actually detect it's being rushed through by looking for unload without load. Note to self and to other page authors: make sure unload handlers don't break if related code in load handlers weren't executed. > We additionally also suggest firing a "load" and so forth > when the user aborts the page, on the assumption that you > probably have all the scripts you need and are only > missing minor things like ads or analytics Makes sense too - the user probably stopped the page when it seemed complete enough to him, so he should get event handlers and all other UI stuff set up that's normally in load handlers. I did a few more tests and found even more differences. Chrome has different behaviour depending on if the navigation is initiated while parsing <head> or <body>, and for the latter it fires the same events as Firefox although in a different order: FF17 Chr23 Chr23 IE9 spec nav head nav head nav body nav head nav head or body or body or body ---------- ---------- ---------- ---------- ---------- beforeunld domload domload beforeunld beforeunld domload unload beforeunld unload unload unload Interesting stuff indeed :-) Best regards Mike
Received on Friday, 14 December 2012 22:29:20 UTC