Browsers - wrong ENTER - TAB key behaviour

While working on iPDF formulars I received a lot of responses from the internet users. Many of them were common inexperienced users with only basic knowledge of how to fill out online HTML forms.

Surprisingly, many responses were complaints about difficulties on filling out my online HTML forms - which is essential for user friendly implementation of the application. After investigation I realized, that the root of the problem is not within my application but it lies within wrong implementation of browser behaviour on HTML forms.

The problem

While being focused on input field - by pressing ENTER, one would expect that focus will move to the following field. Instead all browsers implemented something unexpected - form submission! But if the form contains more input fields (which is typical) - why should it submit? It initiates useless client validation with error messages or perhaps submits incomplete form data. So - how should ordinary (inexperienced) internet user know that he must press the TAB - key in order to move to next input field?

Yeah, yeah I know - they will learn quickly about the TAB key - but that is not the point. The point is that common internet users naturally expect the ENTER key to be pressed once they fill in their data into some input field. Check out demos 2 and 3 and let me know what do you think.

DEMO 1: Default behaviour - on each ENTER the form is submitted, regardless of which field is focused:

Name:
City:
Gender:	YesNo
PHP rocks!:	Yes No

DEMO 2: Natural human behaviour - on ENTER focus to next input element. Form is submitted only when focus reaches the SUBMIT button. User is guaranteed that he passed through all fields:

Name:
Password:
Gender:	YesNo
PHP rocks!:	Yes No

DEMO 3: Form without the SUBMIT button - move to the top first element once reached last element. Missing submit button may be also usefull just like at iPDF formulars. Submitting is possible e.g. by clicking with mouse on button (out of the formular) with javascript handler (e.g. ajax post).

Name:
City:
Gender:	YesNo
PHP rocks!:	Yes No

Javascript - Fix HTML Form behaviour

// changed default form behaviour - each form not having "default"
// in ID attribute will have on pressing ENTER
// focus moved to next input field rather than being submitted.
$("form:not([id*='default'])").keypress(function(e){
	var myForm=$(this);
	if(e.which == 13){
		var $targ = $(e.target);
		if (!$targ.is("textarea") && !$targ.is(":button,:submit")) {
		  var focusNext = false, first = false, isFocused = false;
		  // loop through all form elements
		  myForm.find(":input:visible:not([disabled],[readonly])").each(function(){
				if(first===false){
					// store first element
					first=this;
				}
				if(this === e.target){
					// we just found changed element - following is to be focused
					focusNext = true;
				}else if(focusNext){
					if(this.type !== 'submit'
					  || (this.type == 'submit' && this.id.indexOf('_back')===-1)){
						// do not focus on submit button
						// having "_back" in ID attribute
						isFocused = true;
						$(this).focus().select();
						if(this.type == 'submit'){
							myForm.submit();
						}else{
							return false;
						}
					}
				}
			});
			// we looped through all elements but could not focus on next element
			if(isFocused===false){
				// focus again at first form element
				$(first).focus().select();
			}
			return false;
		}
	}
});

Conclusion

Due to some historical reasons, all browsers implement not natural human behaviour of HTML forms regarding the ENTER key.

Moving to next input element should occur after pressing the ENTER key, not after pressing the TAB key (TAB key behaviour is OK to keep backward compatability). A form should only be submitted on pressing ENTER when focus reaches last form element which should be the SUBMIT button. Additional logic should be applied, e.g. browser should check if the form has multiple input fields and differentiate.

However, I understand that this behaviour might be tricky to implement generally in a proper way. It would be more obvious on pages with many input fields, which is not typical internet (mostly 2-5 fields for registration) use case and kind of specific case for the iPDF site.