Page style:

A Blue Perspective: Don't annoy me with your crappy form field focus

Don't annoy me with your crappy form field focus
27 October 2005

» Improved Form Field Focus «

OK, when you have a page that is mainly about a form, focusing on the first field can be a good thing. Your index finger has a finite number of clicks in it, so why waste them on form elements? Jakob Nielsen even mentioned it among his tips this year, to prevent making one of the Top Ten Web Design Mistakes of 2005.

But, what happens when focusing the first field interrupts the user's flow of action? This:

Name:

Yes, while the page was loading you've already filled out the first field and moved onto the second. By the time you've looked up from your two finger tapping, you see that something's gone awry and your form data is out of whack. Grrrrr.

Solution? Write a field focus script that pays attention to user interaction.

OK, so your JavaScript code just went from 1 line to 78, but with good reason – it's less likely to piss off your users. What the focusField() function on my example page does is:

  1. Check whether the user has focused on a field already. If so, do not attempt to refocus.
  2. Check whether the user has entered data into a form field already. If so, do not attempt to refocus.

The reason the script is extra long, is because handling text selections is probably the worst supported feature in all the browsers. Internet Explorer does it well. Mozilla does it differently, with no support for form field selection. Safari does it slightly worse than Mozilla, Opera worse again, and anything else you shouldn't even think about.

IE is the only browser that lets you tell whether a form field is focused, so it's the only one that executes that step, but all the other browsers check whether data has been entered, so at least you get most of the benefits and reduce your annoyance factor by about 90%.

Even if you don't use this particular script, the one thing that you should take away from reading this is that sometimes the solution can be worse than the problem.

Tested in Internet Explorer for Windows 5/5.5/6.0, Firefox 1.0.4, Opera 8.0, Safari 1.3 and Internet Explorer for Mac 5.2

Update: Bad offender: Google advanced search

Comments

1/16. 27 October 2005 @ 08:42, Antone Roundy wrote:

Another solution that requires less than 78 lines is to use setTimeout to watch for when the browser creates the first form field and then focus on it. That way you don't have to wait till the entire body is loaded, so you can set the focus before the user has time to do any typing. Here's the code (assuming the form's name is theForm and the field you want to put the focus in is theField):

function SetFocus() {
    if (document.theForm && document.theForm.theField)        document.theForm.theField.focus();
    else setTimeout('SetFocus()',100);
}
setTimeout('SetFocus()',100);

2/16. 27 October 2005 @ 11:13, Jonathan Snook wrote:

I'm a little confused. Firstly, why create an array of form elements to check? Why not just loop through all of them regardless? My thoughts are that you'd be able to chop the second part of the script in half. Plus, why not check against the defaultValue (or defaultSelected, or defaultChecked) instead of whether an item is checked or not or has a value or not, since it may realistically contain a default state other than blank?

3/16. 27 October 2005 @ 11:35, Jonathan Snook wrote:

Sorry for the appropriation of content but check out a quick example I put together. And while not officially tested, should work in most browsers.

Any particular reason to use .getAttribute("type") when .type works just fine?

4/16. 27 October 2005 @ 11:51, Rob wrote:

Argh, this is where I wish other browsers were more like IE.  IE has a non-standard activeElement property (http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/activeelement.asp)

It'd be more like:
if(!document.activeElement){
    target.focus();
}

Unfortunately, "There is no public standard that applies to this property."  -- I'm no fan of that phrase, but it drives me nuts when other browsers' adopting the good idea would save me 75 lines of cross-browser compensation like this.

5/16. 27 October 2005 @ 15:43, The Man in Blue wrote:

Antone: Yes, I'd normally use a an element load scheduler but I figure this script is handy for any window.onload jockeys that just want to throw it in.

Jonathan: Good call on defaultChecked/defaultValue, script has been modified. Nothing seems to support defaultSelected, though, and Opera doesn't recognise defaultValue on select boxes, so you have to check for that.

6/16. 27 October 2005 @ 16:16, The Man in Blue wrote:

Oh, BTW, I use getAttribute() because it's more future-proof than using a direct dot property. Once you're in XML land, .type should theoretically have no meaning. But hey, it doesn't make a difference at the moment.

7/16. 27 October 2005 @ 18:17, CornedBee wrote:

Instead of a timer-based JavaScript scheduler, at least in non-IE I'd probably catch the DomMutationEvent.
Using this event, you can get instant notification of element creation.

8/16. 27 October 2005 @ 21:01, danbee wrote:

Maybe I'm just odd, but I hate it when a page automatically sets focus on a form field. It's only one click! I prefer a page that doesn't assume what I'm going to do.

On another note, the comment field doesn't seem to work properly in Firefox 1.5 Beta 2 until I turn Javascript off.

9/16. 27 October 2005 @ 22:43, Jonathan Snook wrote:

Both DOM 1 HTML and DOM 2 HTML have .type as a valid property. I think it would be unlikely that any browser would drop support for these DOM specifications. In XML land, <a> should theoretically have no meaning either. A browser will have to attach meaning to it.

10/16. 27 October 2005 @ 23:21, ppk wrote:

Cameron,

Great idea! But...

Can you please explain why you want to check for a selection? I just don't see the point, and removing this feature would make the script 80% shorter.

I agree with Jonathan that looping through all form fields and check if the current value is different from the defaultValue is probably a better way of doing this.

11/16. 27 October 2005 @ 23:27, The Man in Blue wrote:

Yeah, not checking for a selection would definitely make it shorter.

I was going for the situation where a user has clicked on a field, is maybe thinking, then starts typing, inbetween which the field might have been re-focused.

*shrug* Modify as you see fit. My main point was to try and reduce blanket refocusing. So, if you implement any of these steps, you're heading in the right direction.

12/16. 28 October 2005 @ 09:52, Jo wrote:

I prefer using this method when I *by a ccident* click anf go to another page and would use the back-button, the form would set the focus on the last entry I made, cookies required I guess.

Or use this method for form validation and set the focuss on the field where invalid or empty. Of course other better methods can be used for that such as server-side validation. If available that is ...

This rounds up my thoughts.

13/16. 29 October 2005 @ 02:15, Tony wrote:

Totally agree how annoying that can be. Worst offender is Hotmail (which I use exclusively for giving my email on online purchases...) The page takes forever to finish loading, and MANY times, your password accidently gets typed...in plane view of those around you, on the E-Mail Address line. Just as I'm typing my password, focus shifts to the E-Mail Address line. Horrible...

14/16. 12 December 2005 @ 07:35, Lars wrote:

Makes me remember that once i did a form like that :

- focus on the first field

- if ENTER is pressed, check the required fields are not blank, and focus on the next blank but required field

- if all required fields are filled and ENTER is pressed, send the form

Another one i did for authentication form :

- in the password, field check if the CAPS LOCK is on, and if yes, than display a message alerting the user that CAPS is on, a bit like in MSN Messenger... The only downside is that it can only do the check once the user presses a key, not before.

15/16. 6 February 2006 @ 22:34, Victor wrote:

Will this work with disabled form elements? The Code Project has a nice example taking this into account.

16/16. 15 February 2006 @ 05:42, bart wrote:

Auto focusing an element may sometimes be annoying. I had a search form at the top of the page that I was reusing at the bottom of the results page. When the results page rendered, the page was auto-scrolled to the bottom because of the auto-focus. To view the first result, I'd have to scroll back up to the top of the page. I fixed this once I realized what was happening, but just beware of placement of the form. Autofocus when the field is above the fold.

 

Post your own comments

Fields marked with an asterisk* are mandatory. All HTML tags will be escaped. http:// strings in comments will be auto-linked.