cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 28102] - [PATCH] Client-side: window.onload handler clobbered by <body onload="...">
Date Wed, 31 Mar 2004 22:20:44 GMT
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 ml@wrinkledog.com  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?

Mime
View raw message