DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=28102>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28102 [PATCH] Client-side: window.onload handler clobbered by <body onload="..."> ------- Additional Comments From [EMAIL PROTECTED] 2004-03-31 22:20 ------- Because (a) I had to spend time figuring out why window.onload was getting stomped, and (b) it forces me to put the onload logic in the <body> @onload, and I have "locality" issues with that... the document that cares about the onload logic is nowhere near the html/body element. So I would have to add some mechanism like <page onload="whatever()"> or <page> <body-onload>whatever()</body-onload> Which I could do, of course, but it feels hacky. If forms-lib.js were graceful w.r.t. window.onload instead of suprising/intrusive, I could do <page> . . <content> <script language="javascript"> . . window.onload = whatever; </script> </content> which is the kind of thing that seems like it ought to "just work". (Or more likely I would use an external script, but... same idea). Why can't form_lib.js just assume that there may be a window.onload and be nice to it, instead of having an undocumented restriction that you can't have set window.onload?
