One of the major initial goals of the HTML 5 effort was to update the core HTML form elements to reflect more contemporary thinking. Find out how well the HTML 5 specification has fulfilled that goal so far.
orms have become an integral part of nearly all web applications, but the core HTML form elements are now nearly 13 years old. No surprise, then, that one of the major initial goals of the HTML 5 effort was to update these elements to reflect more contemporary thinking.
One of the W3C's underlying goals when it first laid out the XHTML specification was to create a forms architecture that would better handle XML content. That led to the development of XForms in 2002. However, many in the HTML community felt that the focus on XML rather than on name/value pairs and JavaScript, which had evolved as part of HTML 4, ultimately made the specification too complex or too inflexible for the average web developer.
This reaction could very well have precipitated the creation of a new HTML 5 specification by the self-styled Web Hypertext Application Technology Working Group (WHATWG), whose spec was eventually adopted as a draft by the W3C for the next generation of HTML 5. In the process, the XHTML 2.0 effort was displaced.
The current (August 2009) HTML 5 working draft establishes a few new form elements as well as modifications to existing elements. These changes continue to reflect the underlying data model that HTML 4.0 used, in which each particular form control maintains its own internal state rather than relying upon external resources. However, this process isn't as clearly defined as was in the earlier versions of the language specification.
This article explores the notable new form elements and the modifications to existing elements introduced in the HTML 5 working draft.
Working with Output
Perhaps the most significant of the new forms elements is the <output> element. Just as with the <input> element, the <output> element contains a @value attribute, which reflects its current state value. However, in this case, the value rather than the internal content will be displayed for the element. When the @value attribute (or the element's corresponding .value property) changes, so too will the content.For instance, the following illustrates a simple "Hello, World!" where the target of the hello is an output field:
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>Hello!</title>
<script type="text/javascript"><![CDATA[
function updateHello(ctrl){
var helloOutput = document.getElementById('helloName');
helloOutput.value = ctrl.value;
}
]]></script>
</head>
<body>
<div>Hello, <output id="helloName" value="World"/>!</div>
<input type="button" value="John" onclick="updateHello(this)"/>
<input type="button" value="Paul" onclick="updateHello(this)"/>
<input type="button" value="George" onclick="updateHello(this)"/>
<input type="button" value="Ringo" onclick="updateHello(this)"/>
</body>
</html>The advantages of output may not be obvious right away. After all, you could do the same thing with a <span> element that has the same id value and the .innerText property. However, the <output> element has a few additional properties that make using it more advantageous.
Two attributes, @mode and @defaultValue, allow you to create initial values for the field. When you set @mode to "default" and don't specify a @value attribute, the @value of the output field is the same as the value contained in @defaultValue. If you specify neither, then the result is an empty string (""). When @value changes, so does @defaultValue.
On the other hand, if you set the @mode attribute to "value," then changing the value of @value has no effect on @defaultValue, which consequently can be accessed only by the .defaultValue property.
You can see the results of having created initial values for the field when forms reset. Each form has its own .reset() method, which, when invoked, will cause each element associated with the form to call its own internal reset routines. For output, the effect of a reset is the @value attribute (and consequently the display for the element) is set to the value in @defaultValue. Note that form controls do not need to be contained in their associated form elements. Instead, you can use a control's @form=name attribute to associate a control with a form having the specified name. This can be especially useful for <output>, as this element is the most likely to be contained in text content, well away from the form to which it's linked.
Here is an example:
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>Hello!</title>
<script type="text/javascript"><![CDATA[
function updateHello(ctrl){
var helloOutput = document.getElementById('helloName');
helloOutput.mode="value";
helloOutput.value = ctrl.value;
}
]]></script>
</head>
<body>
<div>Hello, <output id="helloName" defaultValue="World"
form="selector"
/>!</div>
<form name="selector">
<input type="button" value="John" onclick="updateHello(this)"/>
<input type="button" value="Paul" onclick="updateHello(this)"/>
<input type="button" value="George" onclick="updateHello(this)"/>
<input type="button" value="Ringo" onclick="updateHello(this)"/>
<input type="reset" value="Reset"/>
<form>
</body>
</html>Here, the <output> is located outside of the form but is still bound to it via the @form attribute. Its initial value will be "World." When a user presses a button, the first thing that happens is that the @mode attribute is set to "value," enabling the @value and @defaultValue attributes to be decoupled. That way, @defaultValue always retains its initial value (in this case, "World").
When a user presses the Reset button, the @mode for the output field is automatically reset to "default" and the value of @value is set to the value contained in @defaultValue (once again, giving you "Hello, World!"). Whether or not the output so generated can incorporate HTML elements is unclear in the original HTML 5 specification.
When HTML 5 becomes widely adopted, <output> will likely become one of the more widely used elements. This can also serve to dramatically simplify JavaScript coding--especially with specific new document- and form-based events such as onforminput.
Input: The Swiss Army Knife of HTML 5
The <input> element is the workhorse of HTML 4. An abstract entity that is meant to hold a single value, <input> uses the @type attribute to determine its "expression," based upon the type of data that it holds. HTML 5 dramatically expands the set of types (referenced in the specification as input states) to provide different visual interfaces for the most common data types.In a number of cases, the element in question doesn't look any different from a default text field, but it allows you to validate input. In some implementations (such as e-mail input fields), this feature might prohibit people from entering invalid characters. Most of the time, though, the field allows any input value and the control automatically throws a validation error event if the value fails to satisfy a pre-defined pattern (per the type). You can catch the validation error event with the appropriate event handler.
Text, Search, Tel, Email, and URL States
A new attribute for text fields within HTML 5 is the pattern attribute, a regular expression that you can use to provide a match for a given field. If the value in the field does not satisfy the given regular expression, then a validation error is thrown.Text fields can be fairly complex, so HTML 5 provides specialized forms of text fields that have pre-defined patterns: email, url, and tel (for telephone values). In all cases, you can override the internal implementation of these fields by using an explicit pattern attribute value.
Number and Range States
The number state is a text field that will validate only if the value within the field is a number. The @min (minimum) and @max (maximum) attributes can provide additional constraints to ensure that the number is within a given range (@min must be less than @max, of course). You can also set the @step attribute to a specific value (usually 1) to indicate that the number must be given as @min + n * @step, where n varies between 0 and (@max - @min)/@step. Thus, @min="1",@max="5",@step="2" implies that a valid value can be only 1, 3, or 5.Some implementations will represent this field as a spinner, with a read-only text field and arrows for moving between @min and @max values. The range state, on the other hand, is usually represented as a slider, with a thumb button that can "slide" between the minimum and maximum value. Range input fields generally make the most sense when the exact value is less important than the relative value, such as when you set audio volume between silent and max loudness.
Date, Time, and Datetime
Most of these input types combine some kind of date, time, or datetime validation format with visual representations of calendars or clocks. The HTML 5 specification does not provide formal specifications of the visual representations that these fields should use, as long as the end result binds a valid date, time, or datetime value to the field.Valid date, time, and datetime fields make use of the standard W3C representations, so that January 2, 2010 at 10:15:00 PM Pacific Standard Time would be given as 2010-01-02T10:15:00-08:00Z, the fifth week in 2010 would be given as 2010-W05, and January 2010 (a month) would be rendered as 2010-01.
As with numbers, the various time fields also support the @min and @max attributes, allowing you to place limits on what would be valid. This may also be supported by the visual representation of the field. For example, a calendar with a @min of 2010-01 and a @max of 2010-12 would be able to display dates only in the year 2010.
Additionally, the date/time fields support the conversion property valueAsDate, which converts the W3C XML date representation into a JavaScript Date() object, and will also convert such a JavaScript object back into its string representation.
Image State
The image state is a new field type that may prove to be quite useful. This <input> control takes the @src attribute, which should point to an image resource. When you load an image, any time the user clicks on it, the control receives the coordinates of the mouse click relative to the image's origin as the value for the control.The image state has a number of potential applications. It makes it easier to create visual range controls for non-numeric information, such as a gradient indicating the darkness or saturation of a given color. It also can simplify UI development for web games as well as the annotation of image content. You can use it to create quick and dirty area maps as well.
The spec currently is a little ambiguous about the exact nature of the coordinate representation, though it most likely will just be given as a comma delimited XY pair. Different HTML DOM representations already allow you to get mouse coordinates relative to an image, but it's not always easy. The image state will simplify that code and make it possible to be consistent across all HTML 5 browsers.
Color State
The color input type provides a means for selecting a specific color. Typically, it will be implemented as a combination of a text field that validates for color representations, whether #rrggbb, rgb (red, green, blue), or a simple named color ('green','yellow', etc.), and a widget for choosing from an appropriate color selector or well. The specific implementation for the widget will be browser dependent.
Autocomplete, List, DataList, Placeholder, and Autofocus
These are not states but rather attributes that are employed by the input control. Autocomplete on input controls (or forms in general) determines whether the browser (if it supports this capability) will retain a history of previous values for the given input name. When set to off, @autocomplete disables this feature, so that sensitive data (such as nuclear missile control codes— an example given in the spec itself) will need to be re-entered every time. So, next time you're thinking about writing your world domination interface in HTML, remember this property (especially as it normally is on by default).The @list attribute is new to HTML 5, but its behavior is similar to @autocomplete. The @list attribute contains the @id of the <datalist> element, which in turn holds a set of <option> elements. When @list is present, it overrides the default @autocomplete behavior. Instead of showing a history of previous entries, the autocomplete box will show a set of potential default values from the indicated datalist. Think of this as being a list of potential suggestions.
Unlike the behavior of the <select> statement, the autocomplete capability is open-ended. The user can enter in values that differ from those in the auto-suggest drop-down with no problems.
The <datalist> element and its associated options are invisible. The spec is not clear about where you should place <datalist>. Should it be in the header, inline in the body, or even as a child of the <input> element (which, while logical, seems to be contradicted by the assertion that input is a null element that takes no children)?
Another improvement in HTML 5 is the introduction of the @placeholder attribute, which serves to implement what is becoming increasingly common in AJAX-enabled web pages: the grayed out placeholder text in search fields or similar applications that disappears automatically when the user clicks on the element but reappears when the entry clears. Often, this placeholder contains a short instructional phrase explaining what the user should enter, such as "Type Your Search Here." The placeholder text is not passed in to the server when the form is posted. This feature is used most notably with the <input type="search"> element, which otherwise has the same characteristics as an ordinary text field.
Finally, @autofocus is an attribute you place upon an element to indicate that when the page is loaded the element should automatically receive the focus as soon as someone starts to type. It's a Boolean value, so if you explicitly state the attribute (regardless of its value), the behavior will be enabled.
I suspect that @autofocus will cause all kinds of interesting problems, given the difficulties associated with other Boolean attributes such as the @selected attribute for options.
Working with the Form Element
HTML 5 does not radically change forms themselves from their HTML 4 counterparts, though there are a few differences. One of the key changes is the introduction of form names and the use of the @form attribute on form control elements. A consequence of these changes is that form containment is no longer a strict requirement. As long as an element is bound to the form with the @form attribute, it can be anywhere that such an element is allowed.The <form> element supports the @novalidate attribute, which is also Boolean. When present, this attribute indicates that no validation events should be launched. Otherwise, by default, any time a submission occurs, the HTML will perform validation first before changing location to the results of the operation and updating the history.
The <input type="submit"> button includes five new attributes:
- formaction
- formenctype
- formmethod
- formnovalidate
- formtarget
Each of these corresponds to the form attributes of the same basic name (i.e., action, enctype, etc.) and makes it possible for different form submission buttons to override certain attributes on the form. This can be especially handy when dealing with the full panoply of HTTP verbs.
Unlike HTML 4, HTML 5 explicitly recognizes the PUT and DELETE HTTP verbs. As such, HTML 5 can send these methods directly to the server. Many browsers currently support this capability implicitly, but not all do. This support should go a long way towards making RESTful services more viable. For instance, with a form, a Replace button and a Clone button would enable you to use one RESTful URL through both the PUT and POST mechanisms, respectively. POST would indicate that even if a given set of data includes some kind of file identifier, the POST handler on the server should automatically generate a new one for the entry.
Neither the <textarea> nor the <select> statements have any appreciable changes beyond the inclusion of the @autofocus attribute. This seems a little odd in the case of <select>, which seems to be a natural choice for binding to a datalist.
There's currently no indication that the W3C is considering alternate XML or JSON encodings at this time, but this is certainly one area that I think deserves some thought. Even if HTML 5 does not include explicit support for XForms, the potential advantage of creating even simple XML encoding from the control data would certainly go a long way towards making HTML 5 work more effectively in enterprise settings that have complex XML workflows.
What About XML?
As you probably gathered from my comments throughout this article, ambiguity seems to be a fairly common problem with the overall HTML 5 specification, beyond the XHTML representation. The expectations placed on attributes and schema design contributes to the ambiguity, which is compounded by the lack of a formal working schema or DTD. Because of these factors, the specification itself very likely will need another year of work—if not more—before it becomes stable enough to be fully "implementable."Overall, the lack of XML representation in any aspect of HTML 5's form implementation (and the highly underspecified nature of the XML representation) is potentially quite disturbing. The presence of AJAX-oriented features—and their inherent complexities—seems to indicate an understanding of requirements and in my opinion a fairly deliberate effort to marginalize XML in the application design. The W3C should be careful about letting this standard get steamrolled through the recommendation process given these deficits.