- From: <bugzilla@jessica.w3.org>
- Date: Thu, 21 Feb 2013 21:58:11 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21074 Lee Kowalkowski <lee.kowalkowski@googlemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lee.kowalkowski@googlemail. | |com --- Comment #6 from Lee Kowalkowski <lee.kowalkowski@googlemail.com> --- (In reply to comment #0) > The only option now available is the iframe hack described in the attached > URL. ...or just not use the onload event at all! I rarely use it, for good reason - it's always too late, and it's not just other scripts, it's everything! Often I'm halfway through filling out a form when the onload event causes a script to put focus back into the first field as I'm typing. Infuriating! Especially if it's the password I'm currently entering, and now my password is visible. I just scream "Why are they using the onload event?! Why would ANYBODY!!!", haha, really, I do! Too often. Of course the problem is the onload event can be delayed by any resources, not just scripts. Whilst "nonblocking" sounds feasible, I don't think I will be persuaded to use it, because it still won't enable me to use the onload event satisfactorily. If the problem really is that the onload event could sometimes take forever, then best not to use it for anything critical to the user. There is a DOMContentLoaded event which looks more appropriate. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 21 February 2013 21:58:12 UTC