Web Forms 2.0 - notes and comments

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.

Web Forms JavaScript implementation

Most of the Web Forms specification can be implemented in JavaScript right now, and that's exactly what I'm going to do.

More than a year ago I started working on my own form validation script (I don't want to use the word library because I dislike JavaScript libraries, but I'm afraid it might be considered as such). This old script is rather crappy, and I've decided to completely rework it. More importantly, today I decided that the script is eventually going to follow the Web Forms specification.

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.

An early example

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 repeat functionality (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.

My areas of interest

The rest of this page contains suggestions, notes and comments on the Web Form specification. They reflect my main areas of interest: JavaScript and usability.

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

Although in the long term native support will be welcome, conforming browsers will not appear in the near future, and when they do appear other browsers will not support the specification. Besides, any conforming browser will likely support JavaScript, too, so that my script will remain functional.

Such a script requires W3C DOM Level 1 support, so older browsers (Version 4 and below) will never support it. Besides, even users of modern browsers may switch off JavaScript. Server side form validation will therefore remain mandatory (probably forever).

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.

At the moment I ignore the parts of the specification that do not directly relate to a JavaScript implementation or usability, most notably section 5, Form submission.

Custom type values

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.

Reading out 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 element.getAttribute('WFtype') (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 custom attributes.)

Custom tags

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.

Therefore custom tags cannot yet be used.

I suggest replacing <repeat> tags by something like <div WFaction="repeat"> (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 spans).

Templates

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 <repeat> tags 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.

Date formats

Section 2.1: Extensions to the input element, date-related values.

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 date type.

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.

The problem

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.

Form validation

Section 4.4: Form validation. I strongly disagree with this section, since I feel it violates a number of usability rules.

New events

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.

Presenting error messages

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:

  1. User is filling out a form, but isn't paying much attention and skips 10 required fields.
  2. 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.
  3. User sighs, fills out the field, and submits again. Note that he doesn't know that there are other required fields, since he isn't told and he doesn't pay attention to subtle hints like "(required)".
  4. onsubmit the script finds one required field without a value. It flashes an alert and places the focus on the form field.
  5. User gets annoyed, but in a spirit of "what-the-heck" he fills out the required form field. He still doesn't notice that there are 8 more required fields.
  6. onsubmit the script finds one required field without a value. It flashes an alert and places the focus on the form field.
  7. User gets really angry and leaves website, never to return. "Those bloody impossible forms!".

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.

Error message texts

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

Groups of form fields - group attribute

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:

  1. One form serves to order brochures. The possible brochures are named in the form, each preceded by a checkbox. What I need is a simple check to make sure that at least one of these checkboxes is checked. If none is checked (ie. user does not want to receive any brochures), submitting the form is useless.
  2. The other form is a contact form. It contains a lot of contact-related text fields (voice phone, fax, mobile phone, email etc. etc.), and the rule is that the user should enter at least one way of contacting him. Again, without the user giving any contact information submitting the form is useless.

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.

Extending Web Forms towards usability?

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:

Minor stuff

A few minor details.

read-only fields

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.

required on select-ones

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 required check.

autocomplete

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.

In JavaScript, we'd create an 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

Typo in 2.16 under "For parsing errors in HTML": "divine" should (probably) read "define".