However there are a number of important problems not mentioned. If you add behaviour to your document outside of the HTML, there’s a time period where the user can interact with the HTML elements without the proper behaviour, either they’ll trigger the no script fallback - which could be annoying they get a much worse user experience, and you’ve wasted your time writing the script. Or as is more likely for the majority of script developers these days, they’ll end up with nothing happening.
The delay in behaviour loses one of the key elements of UI that of consistency.
You can of course author your script in such a way that this isn’t a problem, however to do that you can’t abstract out your scripts, they have to be inline next to the elements and immediately follow the HTML elements they’re modifying, the onload event is much too late. There is another alternative, that of hiding your content until such time as everything’s been rendered and the behaviour attached, this is far from trivial - how can you be sure you can show it again in a degradable manner? - and of course it makes your site seemingly much less responsive, so I think that is worse.
Seperating script and HTML simply isn’t practical in todays mark-up languages, even if it’s desirable. Simple onsubmit form validation might cut it, just about, because the user is unlikely to interact with the form enough until after the behaviour has been attached, but the more complicated validation that provides real-time feedback, that’ll be down the same problem of “onload=’someformelement.focus()’” where most users are well into the field before being viciously snapped back to the first.
Techniques like XBL, or HTC’s are practical future ideas of how proper seperation of behaviour can be achieved, but I don’t think a retrofit onto HTML is a good idea yet.