Forms - Introducing HTML5 - page 80

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 . But the
coolest features for developers—which will be transparent to
bosses and consumers, but they'll make our lives much easier—
are new form input types which can give us special UIs and
built-in error reporting.
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). In
Chapter 12, we show you a methodology called polyfilling to
ensure that old browsers (and only old browsers) are given a
JavaScript helping hand, while you just code to the standard.

NoTE These form
enhancements aren't imple-
mented across the board yet.
Opera has the most extensive
support, followed by the WebKit
browsers and Firefox. At the time
of this writing, Internet Explorer
10 Platform Preview 2 has some
support. Exciting times!

New input types

The new form fields were the genesis of the spec that became
HTML5, and this is where we see the principle of specifying
backwards-compatible extensions to the language in action. The
extensions are largely new values of the type attribute of the
input element. HTML4 specifies that browsers should assume
<input type=text> if you don't specify a type attribute, or you
use an unknown type. Therefore, legacy browsers that don't
understand the new extensions will fall back to the default and
allow the user to enter data in a plain text field. This fallback can
be detected in script and polyfilled if required so old browsers
can mimic the new behaviours.
The specification makes no requirements on how browsers
should present the new input types to the user or report errors,
and so on. Different browsers and different devices will present
different user interfaces; compare, for example, the different
ways that a select box is shown in Safari on a desktop and an
iPhone ( Figure 3.1 ).