[whatwg] Hacking away on forms ... (fwd)

Dave Raggett dsr at w3.org
Fri Sep 8 09:40:34 PDT 2006

H&kon suggested I forward this to the whatwg list, so here goes.

  Dave Raggett <dsr at w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

---------- Forwarded message ----------
Date: Fri, 8 Sep 2006 16:38:50 +0100 (BST)
From: Dave Raggett <dsr at w3.org>
To: howcome at opera.com
Subject: Hacking away on forms ...

Hi H&kon,

I am hacking away at a cross platform JavaScript library for a 
forms-lite testbed, and hope to contribute to a compromise between 
the WebForms 2.0 and XForms camps. It seems to me that there is an 
opportunity to provide an incremental enhancement to HTML4 forms, 
that is easy to learn, reduces the amount of scripting authors have 
to do, and importantly, is a smooth stepping stone towards the use 
of XForms. What follows is an overview of what I am implementing. 
The testbed will be available in October (I am travelling too much 
in September).

The changes to the input element largely reflect what is in WF2 with 
some additions designed to reduce the need for authors to write 
client side scripts. The validate attribute is a boolean expression 
over fields names. If the value doesn't match the type and validate 
attributes the "invalid" class value is set on the element and may 
be used to alter the styling. The requires attribute is a boolean 
expression like validate, and indicates a value is required. As an 
example, you might be asked to give the name of a guardian if you 
said that your age is under 15. The required attribute could also be 
used on div elements to reveal/hide groups of controls (via an 
associated class value). You can also designate div and fieldset 
elements as repeating groups of controls. The index for a repeated 
group may be used within expressions for constraints within and 
across groups.

A major difference from WF2 is the use of the model-view-controller 
design pattern. The input elements act as presentations with the 
model held as JavaScript objects. This allows for multiple views to 
be kept in sync, as well as orchestrating updates to output fields. 
The getters and setters are associated with the field types, and the 
set of types can be extended by authors if needed. The model is 
automatically determined from the input elements and greatly reduces 
the amount of markup compared with XForms.

p.s. implementing the output element would be a lot cleaner if more 
browsers supported the /> syntax for empty elements that aren't part 
of traditional HTML. IE already does so, but Firefox and Opera do 
not. Firefox is even worse as it coerces the tag name to upper case 
when you inspect the DOM node it creates! Opera and Firefox also 
differ over the amount of whitespace text nodes that are set as the 
content on unknown elements. IE has its own weird worts, although 
strangely, it works rather nicely for non-html markup in XML 
namespaces. IE therefore encourages the use of XML namespaces for 
mixed markup when delivered as text/html.

More information about the whatwg mailing list