[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