Forms, probably the one thing that made the internet popular among the business people. Thanks to this addition to HTML, users are able to interact with a website. Unfortunately, after web forms were first introduced, not a lot has been changed to them. However, with XForms and Web Forms 2.0 on the rise, this is probably going to change. But what are they? What are their new features? And more importantly, which one is going to be superior?

XForms

Lets start with the oldest technology: XForms. XForms 1.0 became a recommendation in late 2003 and an update, XForms 1.1, is already in development. One of the biggest advantages is that XForms is an XML namespace and can therefore be used in a lot of ways as a completely device-independant application. To understand what this means, take a look and/or read the introduction on XForms.

Now that I did my duty to give you a short introduction to XForms, lets take a look at its interesting parts: its features. XForms are always seperated into two 2 parts:

  1. the XForm Model;
  2. and the XForm UI.

The XForm Model is used to describe the form’s data and how to submit it, while the XForm UI is used to make the form available to the user. How the XForms UI should look is not described by the XForms specification in any way, so it’s up to the user agent to render the form in the most usable way. Because of this, it makes XForms very flexible and usable for the user.

First, lets take a look at the XForm Model. This is always defined in the model element. The model can take 3 different child elements:

  • instance;
  • submittion;
  • and bind.

The instance element describes all the data which is to be gathered. Every piece of data gets its own element inside the instance.

The submittion element(s) describe(s) how and where to submit the data. Multiple submittion elements can be added to the model which make it possible to submit data to different servers, or using a different HTTP method. For instance, you can have 2 buttons in your form. One to save the data as a file on the server, and one to submit the data to a form which saves it in a database.

The bind element is where the actual fun begins. Using this element you can create a relation between elements. For instance, using a bind element you can specify that a certain element may only be enabled if the value of another element matches a predefined value. So if you have a form that can be used to pay for something, you can ask the user how he/she would like to pay. This could be either by Paypal, cash or credit card. In this case you can specify only to enable the input field where the user can enter the expiration date if the user selects credit card to be the payment method.

But bind also has other features. Take the type attribute for example. This attribute tells the user agent what data is allowed. Combine this with XML Schema, and you have a very powerful way of specifying what kind of data is allowed. This can vary between strings or integers, but also dates or URIs. If these are not enough, you can of course create your own schema with XML Schema for total control.

Another feature of bind is to calculate an outcome. For instance the combined value of two numbers that the user has entered, or an average, etc. The outcome of this calculation can be displayed on the page without even submitting the form data or using scripting.

Below is a small example of how a model could look like:

<model xmlns="http://www.w3.org/2002/xforms"
       xsd:xmlns="http://www.w3.org/2001/XMLSchema"
       my:xmlns="http://jero.net/lab/xml/ns">
 <instance>
  <my:to/>
  <my:amount/>
  <my:details/>
 </instance>

 <submittion action="pay-me-now.php" method="post" id="pay"/>
 <bind nodeset="to" type="xsd:string"/>
 <bind nodeset="amount" type="xsd:integer"/>
</model>

Because there’s no such thing as stand-alone XForm documents, the model element in the example above would normally be placed inside the xhtml:head element.

Now that we have taken a quick look at the XForm Model, lets take a look at the UI. As I said earlier in this article, XForms does not, unlike HTML, specify how the form controls should look, but what they do. That’s a major difference here, so make sure you understand that. Once you’ve got that pumped into your brain, let’s take a look at XForm’s form control elements. I will compare them with HTML’s controls to make it as easy a possible for you to understand them (isn’t that nice?). But to avoid confusion, I will refer to XForm elements as xform:element and html:element for HTML elements. If no namespace is present, you can asume that the element is part of the XForms namespace.

The input element
Just like HTML, XForms also has this element. However, unlike html:input element, you do not need to specify the kind of form control (input field, password, radio button etc.) because xform:input is only suitable for text. So xform:input will probably render as <html:input type="text">. All other purposes that html:input has are divided into other element which are described below.
The secret element
Unlike you might think, this is not the equavalent of <html:input type="hidden">, but instead it is the equavalent of <html:input type="password">.
The textarea element
Same as html:textarea. However, the cols and rows attributes are not required in XForms (as a matter of fact, they don’t even exist). For visual user agents, you can specify the dimension using CSS.
The output element
As I said earlier in this atricle, you can use the bind element in the XForm Model to calculate something and display it on the page. Together with the ref element we can refer to a bind element to show the outcome of the bind’s calculation.
The upload element
Same as <html:input type="file">.
The range element
This element is something we’ve never seen before on the internet besides in Flash applications. With this element you can specify a value in a certain range. So if you want to let the user choose between the numbers -10 and 10, you could of course use the xform:input element to let the user type the number in for himself. But with the range element you can make it the user easier to select the correct value in the range specified by the min and max attributes.. Accessibility++! However, this is of course nothing new. Just take a look at your volume control.
The trigger element
Same as <html:button> and <html:input type="button">.
The submit element
Same as <html:input type="submit"> and <html:button type="submit">.
The select and select1 element
What!? A number in an element name!? Yes, a number! And you better not mess with it because xform:select and select1 are pretty darn useful. These two elements are not only the equivalents of html:select, but also for checkboxes and radio buttons. All you need to do is put the available options inside the xform:select or select1 and let the user agent decide how it should look. This can be a list of checkboxes/radio buttons, drop-down list, or whatever the user agent think it’s best for the user.The difference between the two elements is that with select1 the user can only choose one value, while the user can select multiple options from xform:select elements.

To give you an example of how an XForm UI may look like, take a look at the possible UI for the model we created earlier:

<group xmlns="http://www.w3.org/2002/xforms">
 <label>Transfer Money</label>
 <input ref="to">
  <label>Receiver</label>
 </input>

 <input ref="amount">
  <label>Amount</label>
 </input>

 <textarea ref="details">
  <label>Additional details</label>
 </textarea>

 <submit submission="pay">
  <label>Transfer!</label>
 </submit>
</group>

As you see, the group element is used to group all the payment controls. In HTML we’d normally use fieldset for this. The xform:label inside the group can be compared with html:legend as they both act as a title for the group/fieldset. The xform:labels inside the xform:input elements are used as text to describe the xform:input element. This is comparable to the function of html:label. The xform:label inside the submit element will probably be rendered as text on a button, just how <html:button>Submit!</html:button> would be rendered.

Web Forms 2.0

Now that I gave you some info about XForms (yes, only some as there is a lot more), lets take a look at XForms’s younger stepbrother: Web Forms 2.0 (WF2). WF2 is developed by the WHATWG which is the same group who’s developing the Web Applications 1.0 specification, aimed at extending current markup languages (HTML 4.01 and XHTML 1.0). The same applies to WF2. Unlike XForms, WF2 does not want to replace current web forms. Intead, WF2 aims at extending current web forms which has one very important advantage: backwards compatibility.

When you’d read the Web Forms 2.0 specification, you’d be delighted with the fact that because of WF2’s backwards compatibility it is very easy to pick up, especially compared to XForms which is basically a pain the ass to learn. Just take a look at the INPUT element. Yes! Exactly the same as HTML 4.01’s INPUT element, although with new values for the type attribute:

datetime, datetime-local, date, month, week and time
These new values tell the user agent that only values that are encoded as defined in ISO 8601 (dates like 1996-01-01T00:00Z). When a WF2 confirming user agent would see an INPUT with either of these values for the type attribute, it could make it the user easy and display the input field as Windows' date selector. This way the user agent can make sure that the submitted date will always confirm to ISO 8601 and the user will have less problems with entering the date (some sites require a specific scheme like MM-DD-YYYY which would cause trouble for European users because they’re used to DD-MM-YYYY).
number
The INPUT will only allow numbers. No explanation needed I hope…
range
Ah, one of the new elements in XForms also found its way into WF2. Just like xform:range, the html:input with the value range for type will allow the user to select a value in the range of the numbers specified by the min and max attributes.
email
Once again, I think this input type would cause no problem understanding.
url
Same here…

If you still don’t like the new values for type, you can write your own regular expression that should be used to validate the user input. This regex can be included in the pattern attribute which will be used to validate the user’s input upon submission.

Of course, the additions to WF2 do not limit themselves to input types. Take the required attribute for example. If there is a form control forgotten that has the required attribute, the user agent should not submit the data. The same applies to the type and pattern attributes if a value is submitted that does not meet its field type.

Another new element we see in WF2 is the DATALIST element. This element allows the author to specify a list of default values for, for instance, a text field which will have a somewhat similar effect as your browser’s address bar. Once you click on the arrow at the right of it, a list of IRIs which you previously visited appear. You can think of the DATALIST element to contain such a list of options which can be selected by the user in the INPUT is he wishes to do so.

And I could go on and on and on about all the new features in both specifications. I didn’t even talk about Web Forms 2.0’s repetition model, XForms’s Repeat Module and the new events! However, doing all this research on these two forms did made me understand the two a lot more. Not only did I learn about the new stuff they bring, but also that it’s not 100% fair to compare the two with each other. First of all, the Web Forms 2.0 is still a Working Draft while XForms 1.0 is already a W3C Recommendation since October 2003. The WF2 specification also says that Web Forms 2.0 aims to simplify the task of transforming XForms 1.0 systems into documents that can be rendered on HTML Web browsers that do not support XForms. Therefore we can’t really talk about two competing standards.

However, I think it’s clear that both are at least much, much better than the forms we have now. XForms of course being the more powerful of the two. Its power is incredible thanks to the powerful XML functions that allow the use of multiple namespaces in the same document. However, due to the lack of native support for XForms (only Firefox 1.5+) and XML in general (Internet Explorer), it’s going to take a long time until we can use this awesome namespace.

And that’s the sole reason why WF2 was born: because we have to wait for such a damn long time. Thanks to WF2’s backwards compatibility, we can use most of XForms’ features without discriminating legacy browsers like Internet Explorer because WF2 support is not needed to complete the form. The only advantage that WF2 adds is the fact that forms become a lot more usable for the user when the user’s browser supports WF2. Hopefully modern browsers like Firefox, Opera and Safari can use WF2 to win more users.

However, in the long run, I don’t see WF2 surviving. I still think XForms is a lot better, and once it gets proper support, I’m sure we can say goodbye to WF2. Now don’t get me wrong on this. I still think that WF2 is a great extension to current web forms until the browsers ship with native XForms support and I can’t wait for Firefox to support it.