Forms - Introducing HTML5 - page 68

We HTML, and now it s us back

HTML5 makes developing forms quicker. There are some nice
goodies like the addition of two HTTP types of form action
( update and delete ) to go with the current get and post .
More sexily, a number of elements that were previously required
to be within a form element ( <button> , <fieldset> , <input> ,
<label> , <select> , <textarea> , plus <object> and the new ele-
ments like <keygen> , <meter> , <output> , and <progress> ) can be
anywhere on the page and associated with a form using a form
attribute pointing at the id of its form owner.
Consider this example:
<form id=foo>
<input type=”text”>
...
</form>
<textarea form=foo></textarea>
The <input> is owned by the form foo , as it is contained within it
and it does not have a form attribute overriding that ownership.
The <textarea> is outside the form, but is still owned by it, as its
form attribute points to the id of its form owner.
This gives a lot more fl exibility with styling when you want
those elements to appear visually (and structurally) outside the
parent forms.
But the big wins are the new HTML5 form types and the built-in
validation that they bring. Eventually, you won't need JavaScript
validation at all for these fundamental data types, although you
can't mothball your scripts yet—the new input types degrade
gracefully but will need your JavaScript until the golden future
when everyone has an HTML5 browser (or your boss tells you
that users of ancient browsers will just have to put up with
server-side-only form checking).

New input types

The new form fi elds were the genesis of the spec that became
HTML5, and it's where we see the backwards-compatible exten-
sion principle in action. The extensions are largely new values of
the type attribute of the input element. As all browsers default