Written on 10 June 2004.
In his Web Forms 2.0 specification, Ian Hickson extends the HTML 4.01 Forms specification to allow Web authors to easily add validation requirements to form fields. This page contains my notes and comments on the 9 June version of this specification.
Hickson's specification bridges the gap between current practice in form validation and W3C's XForms specification that, though interesting in theory, has no connection at all to everyday reality. When, months ago, I saw an earlier version of Web Forms, I decided that this is the workable, useful specification I've been looking for to help me make the forms I create for my clients more user-friendly, especially in input validation.
Practical considerations (money and time, mainly) require me to postpone the Web Forms compatible version of my script, though. I'm going to rework the core functions of my old script first, but it has to be backwardly compatible with the forms I already deployed on a few websites. These forms use my own, proprietary set of HTML attributes, so that the next version will not yet be Web Forms compatible. Neither will I publicly release it.
Only after this 2.0 version of my script is finished will I start working on the Web Forms compatible 3.0 version. Don't expect too much too quickly. The 3.0 version will certainly not be released before winter 2004/5.
This ING test mortgage form created in May 2003, certain aspects of which I discuss
in my article Forms, usability, and the W3C DOM, represents my earliest attempt at a modern
form validation script. It uses the almost-Web Forms-compatible
required="true" attribute to
indicate required fields, connected to a user-friendly way of presenting error messages.
The form is in Dutch, but you'll get the picture. Press the orange "Ga verder" button at the bottom of the screen and see the error messages pop up. Incidentally, I feel that this way of presenting error messages is superior to the method proposed in Web Forms. I'll discuss this later.
The form contains my Extending Forms script to generate sets of form
fields, which could be considered an early implementation of the Web Forms
(though I don't actually use the tag, which is impossible anyway due to browser considerations).
The repeat is on page 2 of the form. Switch off the error message by checking the checkbox at the very bottom of the page, press "Ga verder" to go to the next page and press the "Meer velden" button to see the repeat in action.
The form also contains a DHTML script that breaks it up into easily manageable sections. Although this sort of user interaction is currently not a part of Web Forms, it's nonetheless useful for web authors to keep the possibilities of DHTML in mind when creating large and complicated forms.
I shamelessly interpret Web Forms as a specification for a script (library), and will entirely ignore the possibility of Web Forms being natively supported by any browser (ie. without any scripts being necessary to perform the checks).
Such a script must work in the current generation browsers, Explorer Windows 5+, Mozilla 1.6 (or thereabout), Opera 7 and Safari 1.2 . I hope to get it working in Explorer 5 on Mac, too, but I'm afraid its W3C DOM implementation is too buggy to allow this.
My second area of interest is usability. Any form extension must serve to make the form more usable, so that users are more likely to submit the form, giving the owner of the site more feedback, and probably more transactions. Therefore my take on Web Forms is commercial in scope.
Web Forms heavily depends on as yet unsupported values of the
type attribute of a
form field. This simple test tries to read out such custom values.
element.type from a form element with a custom value works only in
Mozilla. Reading out
element.getAttribute('type') works in Mozilla, Explorer Windows
(but not Mac) and Safari.
Therefore custom values of the
type attribute cannot be used at the moment.
I suggest adding a (temporary?) attribute
WFtype as an alternative. This attribute
doesn't exist at all, and can therefore be safely read by using
(sounds odd, but it's true).
(I'd like to use the more descriptive
valueType, but Opera refuses to get
its value it for obscure reasons. Opera is by far the most annoying browser when it comes to reading out
Web Forms uses custom tags, most notably the
<repeat> tag, which should
be replaced by a cloned set of form fields.
Try this simple test.
<repeat>tag but seem to insert the test paragraph before it. Any text contained by the
<repeat>tag remains visible. (This is no problem in Web Forms, though, since it uses empty
Therefore custom tags cannot yet be used.
I suggest replacing
<repeat> tags by something like
(or whatever, as long as it uses an existing tag with a non-existing attribute).
output tags will also have to replaced by existing tags (probably
Section 3: Repeating form controls.
I fully support the idea of templates (in fact, I wrote the first template script
back in November 2002, so maybe I even invented them). Although we cannot use the
specified by Web Forms 2.0 as yet, we can probably devise another way of adding this functionality.
What I'm missing, though, is flexibility. Right now it seems that the specification only allows for repeating templates as children of the same parent node, and every node may contain only one template/repetition among its children. (Correct?)
I feel that this system is too restrictive. For instance, a template might be a bunch of Address fields, including number, street, postal code, city, country etc. I'd like to be able to use this template throughout the form.
For instance, forms for an an online gift service might use this Address template both in the "Sender" and in the "Recipient" sections of the form. These sections might have different parent nodes (say, divs with DHTML behaviour to make sure the user sees only one of these sections at a time).
Besides, between the Sender and Recipient sections we might put the bit where the gifts are actually selected, using, of course, a Gift template. If the Sender and Recipient sections would have the same parent node, the Gift section would be a child of this node, too, which results in two templates as children of one node.
I feel we need an ID of some kind that specifies which template a
<repeat> tag copies.
Maybe something like
<div WFaction="repeat" WFtemplate="Gift">
I feel the Add, Move and Delete buttons should use a
<button> tag instead of
<input> for backward compatiblity with really old browsers. They'd show a normal
text field instead of a button, which would confuse the users.
Section 2.1: Extensions to the
Although in principle it's a good idea to define better ways of handling date and time (anything is better than the current chaos), I recently encountered a practical problem that might make the Web Forms proposal less ideal for everyday applications.
For a while, I used a set of
selects to generate dates, which could be seen as a primitive
precursor of Web Forms's
My main reason for this solution was that it severely restricts the data the user can enter. In fact, the only possible user error in this implementation is the entering of a non-existing day (30 February, for instance). A simple script suffices to catch these errors.
The proposed Web Forms date formats would use different widgets, but the validation script would work roughly in the same way.
A client asked me to implement a date of birth check in a Web form. The old version of the site already used select
boxes to receive this date. When I suggested continuing the triple
select solution, though,
the client immediately and expressly vetoed my proposal. He had excellent reasons for doing so.
The problem, my client explained, was that many users didn't bother to enter their correct date of birth. Their birth year was already known from a previous form, but when asked to provide month and day, too, many users simply ignored the fields, causing the form to be submitted with the default date of birth, 1 January.
This presented severe problems to my client, whose back office needed an exact date of birth. Therefore
we decided to use open
input fields (which caused severe problems in the validation script,
but that's another story).
Would Web Forms's proposed date types suffer from the same problem? I'm afraid so, since any widget that offers a default date and expects the user to enter a real date could be ignored by time-pressed users.
We cannot disallow the default date, since in a very few cases the default might be the actual date the user wishes to enter. Using an empty default ("Select a date") might not work, either, since users might quickly select the first option after this default, especially in select boxes or similar widgets. The calendar example might not suffer from this problem, although it might be harder to use than a select box.
At the moment I have no idea how to solve this problem.
Section 4.4: Form validation. I strongly disagree with this section, since I feel it violates a number of usability rules.
First of all I'm not sure if we need new events. The old ones will serve fine, and inserting new ones will require a lot of extra coding for no purpose I can see.
I feel that an
invalid event is only necessary if we allow implementations
to validate the form at any point in time, instead of only when the user submits the form. From
a usability point of view this is a very bad idea, since validating form fields while the user is
still busy filling out the form could become a fatal distraction.
For a while,
blur-based form validation scripts enjoyed a moderate popularity.
As soon as the user leaves a form field, it is checked for errors and the user is immediately
notified. Unfortunately this very notification is extremely annoying to the user (especially in
combination with alerts). He doesn't want to be disturbed while filling out a complicated form.
I think it's dangerous to change the traditional
submit-based form validation. When
the user submits the form (or moves to a next page, for a form divided into sections), he implicitly states
that he thinks he has entered all data correctly and that he's ready to receive feedback. A form should
never be validated at any other point in time.
Since a form should only be validated at submission time, I feel that the extra events are unnecessary.
Worse, they could lure inexperienced web authors into reviving
blur-based form validation,
with all usability disasters this entails.
If possible, I disagree even stronger with this paragraph:
If it was fired during form submission, then the default action is UA-specific, but is expected to consist of focusing the element (possibly firing focus events if appropriate), alerting the user that the entered value is unacceptable in the user's native language along with explanatory text saying why the value is currently invalid, and aborting the form submission. UAs would typically only do this for the first form control found to be invalid; while the event is dispatched to all successful but invalid controls, it is simpler for the user to deal with one error at a time.
I feel that this is exactly the wrong way to go about presenting error messages. Consider the following scenario:
onsubmit(and not before!) the script finds one required field without a value. It flashes an alert and places the focus on the form field.
onsubmitthe script finds one required field without a value. It flashes an alert and places the focus on the form field.
onsubmitthe script finds one required field without a value. It flashes an alert and places the focus on the form field.
Alerts should not be used (except maybe for one generic warning "Errors have been found; you cannot proceed"). Instead, all error messages should right away be written next to the form field they apply to. (Optionally, we could place the focus on the first invalid form field.) This way, the user immediately gets complete feedback and his level of irritation would remain manageable.
In a heavy duty W3C DOM scripting environment, generating such error messages is a trivial task. See my ING test mortgage form for an example. Press the orange "Ga verder" button at the bottom of the page to see the system in action.
The Web Forms specification is silent on the topic of error message texts. In my opinion it should include a system for defining both general and specific error messages.
Obviously, most error messages would be standard. "This field is required", "This field requires a date", etc. At the moment these error messages seem to be defined within a script, but I feel they should be integrated in the XHTML, especially if Web Forms is ever to become a non-scripted (ie. "native") browser functionality.
Furthermore, a few form fields might need more specific error messages, so there should be a way of overruling general error messages in specific circumstances.
I'm envisioning something like:
<form> <span class="errorMessage" WFfor="required">This form field is required</span> <span class="errorMessage" WFfor="number">This field requires a number</span> <input WFtype="number" precision="float" name="height" required="required" WFerrorMessage="We need to know your height (in meters) because you might not fit in all our cabins"> </form>
We'd hide the spans by CSS, and read out the error messages as necessary. The "height" field has a special error message, since it's unusual to make this a required field, so the user needs some extra information.
(Eventually the spans would have to be replaced by other tags, but for now we need existing tags).
I'm missing one feature in Web Forms, a feature that I've decided to implement in my script. It should be possible to add a check on a group of elements to see if at least one of them has a value.
There is a practical need for such controls. I'm currently working on three sets of forms, two of which need a group check:
I propose something like the following:
<input type="text" group="contact" name="voicephone"> Voice phone <input type="text" group="contact" name="fax"> Fax <input type="text" group="contact" name="mobile"> Mobile phone <input type="text" group="contact" name="email"> Email
If the user fills out none of the form fields in the "contact" group, an error message is shown and the form is not submitted.
It might be useful to extend Web Forms so that it also takes more general usability questions into account. Right now the focus of Web Forms is very much on validation, but the general presentation of forms (especially long and complicated ones) also deserves attention.
I was thinking of the following points:
A few minor details.
I feel read-only fields are unnecessary. If they're read-only, they don't need to be a form field. If the form somehow needs the data, make them hidden fields. If the user needs to see the data, too, print out the data as normal text.
Older browsers don't support
read-only, so the form fields are editable in those browsers,
and edits may cause serious back-end problems.
Simply leaving out the (visible) form fields solves this problem.
I feel the
required attribute on select-ones is unnecessary. If a select-one (or a group
of radios) is required, I always solve the problem by checking/selecting one of the options. As a result
there's always a value.
The code example in section 2.10 is incorrect: one of the options is automatically selected, so it'd
always pass a
I feel the default value of
autocomplete should be
off. In general only a
section of the form would have to be remembered, and besides there's the question of backward compatibility
with existing systems like online banking sites.
autocomplete function by cookies, most likely, and I'd like
to make sure that the cookie wouldn't contain too many fields (especially free textareas with wraps and
such would be a problem).
Typo in 2.16 under "For parsing errors in HTML": "divine" should (probably) read "define".