Pet peeve: Login forms that move the cursor to the username field AFTER the page finishes loading. Sometimes I’m already typing by then.
While working on a website for work, I inadvertently discovered why a web application I use frequently has the annoying habit of moving the cursor to the username field when I’m halfway through typing the password.
The basic way to set initial focus on a form field is to use JavaScript like this:
document.loginForm.usernameField.focus();
You can either embed it in the HTML after the form, or call it in the page’s onload() function. The problem with using onload is that it fires when everything is loaded, which means it waits for images, plugins, and so on. That’s very useful for some tasks, but isn’t the best choice here.
I’m impatient, especially with login forms. I don’t need the logos and background, I want to type in my username and password as quickly as possible and start using the app. Since this particular site isn’t exactly the fastest around, invariably the images don’t finish loading until I’ve started typing the password — and suddenly I’m typing the second half of the password in the username box.
Needless to say, I’m using the inline method on the site I’m building. Not that the login page has any images right now, but if I add any later on, it’ll save the users some aggravation.
Note: I’ve attached a 2009 tweet and the subsequent LiveJournal discussion to the original 2005 article.
Pet peeve: Login forms that move the cursor to the username field AFTER the page finishes loading. Sometimes I’m already typing by then.
Thank you!!! I hate that SO MUCH.
I think some developers have just gotten it into their heads that the way to run scripts is through event handlers and external script files, and something simple like putting a one-line inline script in the middle of the page, right after the form code itself, is somehow abhorrent to them.
To be fair, the consensus, at least among developers (and computer science professors) I know, is that it’s stylistically better to avoid inline script wherever possible. IMHO, developers should never move the cursor except as a predictable response to appropriate user input (e.g. it’s okay to move the cursor from the area code box of a phone number to the box for the first three digits proper after I’ve typed the area code (though I’d prefer if pages that do so would remember when they’ve just done it and ignore a subsequent ‘tab’ press)).
Stylistically cleaner, but IMO there are times when usability (or even functionality) are more important than coding style.
Edit: Not that one should ignore coding style entirely — just that if they come into conflict, such that sticking to the style would result in significantly worse performance, user experience, etc., one is better off breaking out of the style in that case.
Certainly.
Now, keep in mind web development’s not my primary focus. I’ve made a few minor changes to some asp.net pages for one of my company’s products, but most of my experience is in Windows-based applications. Nevertheless, I’d be astonished (and a bit disgusted) if there isn’t an easy way to specify a default cursor position without resorting to inline script.
Edit: And making it happen before the page finishes loading.
There’s an autofocus attribute in HTML5, but it’s still in development and I think Opera’s the only browser that supports the attribute so far. (Most of the current non-IE browsers have partial HTML5 support, but of course they all support different parts of the spec.) Which means a scripting workaround is necessary to make it work for 99% of web users.
At its heart, HTML is still a document markup language, with various capabilities tacked on over the years in an ad-hoc manner. HTML5 is the first update to really take into account the fact that people are using it as an application platform.