Skip navigation.

exploreopera

| Help

Sign up | Help

Posts tagged with "wf2"

re-invented wheels

, ,


The HTML input element already defines a type attribute so it was a matter of adding new values, and my experiments looked at doing so for number and date. This worked fine on most browsers, but the Opera browsers handling of the type and required attributes made it necessary to support datatype and needed as alternatives.

(source)
Well, that's the sort of problem you get when re-inventing wheels: you have to figure out how to fit them in next to the wheels already in place. Meet the JavaScript car mechanic:
  // partial work around Opera's WF2 implementation for type
  // same technique doesn't work for required attribute :-(

Doesn't work for "required"? Seems like the JavaScript mechanic left his "removeAttribute" tool at home.

  if (nativewf2)
  {
    fields = document.getElementsByTagName("input");

    for (i = 0; i < fields.length; ++i)
    {
      field = fields[i];
      type = field.getAttribute("type");

      if (type == "number" || type == "date")
      {
        field.setAttribute("datatype", type);
        field.setAttribute("type", "text");


Look at those final setAttribute statements: since Opera's WF2 wheels apparently aren't good enough they are dismounted and the fancy JavaScript-required-XForms-Lite-wheels fitted instead. Why can't the mechanic simply say "OK, this car already has wheels so I don't need to do any work here"?

Are the differences between XForms Lite "date" and WF2 "date" so severe?

Why would one "required" be better than the other (besides from "required" being invented there while "required" isn't, that is..)?

how to use or survive WebForms2

, , ,

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

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..)