views:

118

answers:

7

As an answer to the question of 'How do you automatically set the focus to a textbox when a web page loads?', Espo suggests using

<body onLoad="document.getElementById('<id>').focus();">

Ben Scheirman replies (without further explanation):

Any javascript book will tell you not to put handlers on the body element like that

Why would this be considered bad practice? In Espos answer, an 'override' problem is illustrated. Is this the only reason, or are there any other problems? Compatibility issues?

A: 

I suppose this has to do with other javascript files also. If some of your javascript files contain a handler for body onload, and if you supply an inline body onload handler in your page then the handler inside the script won't be executed.

rahul
+4  A: 

Using onLoad is becoming less and less common because callbacks can't be stacked using this method, i.e. new onload definitions override the old ones.

In modern frameworks like jQuery and its .load(), callbacks can be stacked and there are no conflicts when using different scripts, plugins, etc. on the same page.

Also, it is widely regarded good practice to keep the markup separate from the code, so even if one would want to use onload (which is perfectly okay if you control the complete environment and know what you're doing) one would attach that event on the scripting side either in the head or a separate javaScript file:

document.body.onload = function() { document.getElementById...... }
Pekka
A: 

Well, '<id>' is an invalid id value if you ask me. I wouldn't use any characters like this.

And for good practice, it's better to use window.onload IMO and place it in the <head> tag. OR Better yet, you can move it to a .js file and cache it for speed.

SoLoGHoST
A: 

As a more non-javascript related answer, the presentation layer of you application could be in the form of templates or even nested templates (dreamweaver or Master Pages etc) where having specific code in the body tag may not be required or conflict with other code required when the template is "inherited"

Mark Redman
A: 

I can see no other reason than the possible later override, which would lead to your code never being executed. Also, obtrusive javascript is not in very high regard anymore.

You should instead assign a function listening to the event. You can do it like this:

function onloadFocus() {
    document.getElementById('<id>').focus();
}

if (window.addEventListener) {      
    window.addEventListener('load', function(e) {onloadFocus();}, false);} 
else if (window.attachEvent) {
    window.attachEvent('onload', function(e) {onloadFocus();}); 
}

...or rely on a javascript framework, such as jquery, that would provide the same functionality for you.

nikc
+1  A: 

There's nothing wrong with using the onload attribute in the <body> element, provided:

  • you have complete control of the page
  • no other script that you use on the page currently or could have in the future will try and set an onload handler on the body element or the window object
  • you know your own mind and are happy to have a small piece of script in your mark-up.

It's also worth noting that <body onload="..."> is a part of a formal standard (HTML 4) while window.onload is not, although it is implemented in all the major browsers going back many years.

Tim Down
Indeed traditionally *nothing* about the `window` object was formally standardised. This is being fixed now: HTML5 [standardises](http://dev.w3.org/html5/spec/Overview.html#the-window-object) this part of the browser object model, including `onload`.
bobince
+1  A: 

Disregarding the issues of whether inline event handler attributes are a wrongness for a moment, the onload event is a poor place to put an autofocuser, since it only fires when the whole page is loaded, including images.

This means the user will have to wait longer for the autofocus to occur, and if the page takes quite a while to load they may already have focused elsewhere on the browser page (or chrome, such as the address bar), only to find their focus stolen halfway through typing. This is highly irritating.

Autofocus is a potentially-hostile feature that should be used sparingly and politely. Part of that is reducing the delay before focusing, and the easiest way to do that is a script block directly after the element itself.

<input id="x">
<script type="text/javascript">
    document.getElementById('x').focus();
</script>
bobince
Very good that you mention this fact. This is a feature request which I got from a lot of users. I don't know if this has anything to do with their low experience level, and and frankly I don't know of any good alternatives to the js trick. It would be great if browsers would have an option of giving focus on the element with lowest tabindex, which more experienced users could opt out on. I personally find it very annoying, but I don't know how to find a good middle way.
disown
Maybe one could implement 'focus follows gaze', since that seems to be what my users want :)
disown
+1. Fully agree, and I considered making this point but ran out of enthusiasm after writing about the `onload` issue.
Tim Down