Forms - Introducing HTML5 - page 82

This will update the value of the aria-valuenow attribute, and can
be tested if you inspect the element using a DOM inspector.

Backwards compatibility
with legacy browsers

The big question is: What can we do for legacy browsers?
The answer is that you don't retire your pre-existing JavaScript
validation just yet, but you leave it as a fallback after doing
some feature detection. For instance, to detect whether
<input type=email> is supported, you make a new
<input type=email> with JavaScript, but don't add it to the page.
Then, you interrogate your new element to fi nd out what its type
attribute is. If it's reported back as “email”, then the browser
supports the new feature—so let it do its work and don't bring
in any JavaScript validation. If it's reported back as “text”, it's
fallen back to the default, indicating that it's not supported. So
your code should load in an alternative validation library ideally
through a lazy load technique so that by default, HTML5-aware
browsers don't need to download and process JavaScript that
isn't required.
var i = document.createElement(“input”);
i.setAttribute(“type”, “email”);
return i.type !== “text”;
Yo u c a n t e s t a t t r i b u t e s , t o o :
return 'autofocus' in document.createElement(“input”);

NOTE Alternatively, you
can use the Modernizr
library to do this work for you.
Modernizr is a small library
(currently 7K) that performs
feature detection and returns
JavaScript Booleans like
Modernizr.inputtypes[email]
set to true or false. There are
some gotchas (watch out for
WebKit!) but it's under active
development. You can download
it from www.modernizr.com .

Watch out for WebKit

It's worth noting that currently the desktop-based WebKit browsers,
namely Safari and Chrome, both claim to support types: email, url, tel,
and number using these detection methods. In fact, the live produc-
tion browsers don't have this support as yet, and it's only reported this
way because Mobile Safari (which is also WebKit) supports these input
types to provide custom keyboards depending on the type (as shown
on the iPhone in Figure 3.8). This is the browser providing device-
specifi c support, typically via the keyboard (in particular on the
iPhone), depending on the input type.