HTML and CSS Reference
with legacy browsers
The big question is: What can we do for legacy browsers? The
dation or fancy DHTML datepickers just yet, but you leave them
as a fallback after doing some feature detection.
As we've seen before, browsers will fall back to using input
type=text whenever they encounter a type that they don't sup-
port. So, a legacy browser, faced with input type=email, will sim-
ply change it to an input type=text. This change also happens
in the DOM and, by checking the type of the input, we can pro-
grammatically determine if the browser supports the new fancy
elements, and act accordingly if not.
For instance, to detect whether <input type=email> is supported,
don't add it to the page. Then, interrogate your new element to
find 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
as “text,” it's fallen back to the default, indicating that it's not sup-
ported. So your code should load an alternative validation library,
ideally through a lazy load technique.
var i = document.createElement(“input”);
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”);
So what does this buy you? First and foremost, you're making
your forms usable and accessible, providing easy entry mecha-
nisms like datepickers and validating user input before it even
goes on a roundtrip to the server. Secondly, you're doing it in a
resource-friendly way, using the browser's built-in capabilities
(if they already understand client-side validation and the new
html5 types/attributes) or, for legacy browsers, gracefully patch-
See Chapter 12 for a methodology and discussion of how to
shoehorn support into older browsers.