how to use or survive WebForms2
Thursday, 21. September 2006, 14:59:31
EDIT: New and improved version of this blog post here:
http://dev.opera.com/articles/view/making-legacy-pages-work-with-web-forms/
Forms need validation. User-friendly, helpful, client-side validation. Plenty of validation examples exist, using JavaScript of various flavours.
The WebForms2 attempts to extend HTML4's form features and one of the objectives is to add support for common validation scenarios.
Being an early implementor of WebForms2 we've seen a few cases where WebForms2 attributes conflict with existing custom attributes (or runs into simple markup mistakes). Generally there are two cases of problems, either the built-in validation unexpectedly prevents form submits, or unexpected new properties confuse JavaScripts that look for custom ones.
Here are some suggestions for webmasters on how to handle problems:
Case: Opera's validation kicks in and prevents your form from submitting
Here you can be a fireman or an innovator - or both. To be a Fireman and just stamp out the problem, you can add a tiny touch of JavaScript to handle invalid events and sort out the issues. For example, to make Squidoo's login work, the fireman approach might be
To be an innovator, make sure your custom attributes match the definition in WF2. For example, the problem with
is that the pattern attribute should be a regular expression.
(I know that's simplistic, I just don't want to divert into the endless debate about finding the perfect regexp for E-mail addresses..)
Now, the validation script needs to be updated to take that into account of course. First of all, it can "learn" not to validate forms in WF2-browsers since that is handled by the browser. For example on Squidoo, they have a function called validate that receives a form as its argument. They could write
..then rewrite the part that checks the "pattern" attribute for the other browsers to read the regexp directly from the pattern.
JS being confused by new built-in properties
FreeParking's domain lookup is broken in Opera 9. The reason is that the script finds input.min and input.max attributes, both are empty but since they are not null the script thinks the domain name is supposed to be a number.
The only real fix for that is to audit your custom attributes and make sure they do not conflict with WebForms2. The fireman could of course also check if a WF2-browser is used, meaning
becomes for example
since if willValidate is defined the UA would handle min and max with its built-in validation. (Of course they could also just remove the null comparison since the empty strings will evaluate to false anyway - but they may want to be able to set an empty min or max attribute to trigger number validation..)
http://dev.opera.com/articles/view/making-legacy-pages-work-with-web-forms/
Forms need validation. User-friendly, helpful, client-side validation. Plenty of validation examples exist, using JavaScript of various flavours.
The WebForms2 attempts to extend HTML4's form features and one of the objectives is to add support for common validation scenarios.
Being an early implementor of WebForms2 we've seen a few cases where WebForms2 attributes conflict with existing custom attributes (or runs into simple markup mistakes). Generally there are two cases of problems, either the built-in validation unexpectedly prevents form submits, or unexpected new properties confuse JavaScripts that look for custom ones.
Here are some suggestions for webmasters on how to handle problems:
Case: Opera's validation kicks in and prevents your form from submitting
Here you can be a fireman or an innovator - or both. To be a Fireman and just stamp out the problem, you can add a tiny touch of JavaScript to handle invalid events and sort out the issues. For example, to make Squidoo's login work, the fireman approach might be
document.addEventListener( 'invalid' ,
/* when an invalid event occurs, the user is trying to submit a form with invalid fields */
function(e){
var input=e.target;
if(input.validity.patternMismatch){ /* value crashed with pattern attribute */
e.target.removeAttribute('pattern');
}
e.preventDefault(); /* do not show validation error */
if(validate(e.target.form)) e.target.form.submit(); /* make sure form submits (Opera bug workaround) */
}, false );To be an innovator, make sure your custom attributes match the definition in WF2. For example, the problem with
<input required="true" pattern="email" type="text" value="" tabindex="1" name="email_address" id="email_address" />
is that the pattern attribute should be a regular expression.
<input required="true" pattern=".*@.*\..*" type="text" value="" tabindex="1" name="email_address" id="email_address" />
(I know that's simplistic, I just don't want to divert into the endless debate about finding the perfect regexp for E-mail addresses..)
Now, the validation script needs to be updated to take that into account of course. First of all, it can "learn" not to validate forms in WF2-browsers since that is handled by the browser. For example on Squidoo, they have a function called validate that receives a form as its argument. They could write
function validate(form){
if(form.checkValidity){ return; } // browser has built-in validation
..then rewrite the part that checks the "pattern" attribute for the other browsers to read the regexp directly from the pattern.
JS being confused by new built-in properties
FreeParking's domain lookup is broken in Opera 9. The reason is that the script finds input.min and input.max attributes, both are empty but since they are not null the script thinks the domain name is supposed to be a number.
The only real fix for that is to audit your custom attributes and make sure they do not conflict with WebForms2. The fireman could of course also check if a WF2-browser is used, meaning
if (e.numeric || (e.min != null) || (e.max != null))
becomes for example
if ( e.willValidate==null && ( e.numeric || (e.min != null) || (e.max != null) ) )
since if willValidate is defined the UA would handle min and max with its built-in validation. (Of course they could also just remove the null comparison since the empty strings will evaluate to false anyway - but they may want to be able to set an empty min or max attribute to trigger number validation..)
