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:
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 workif not morebefore 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 featuresand their inherent complexitiesseems 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.