In this tutorial, we’ll continue developing our HTML5 form. In the last tutorial, we styled the form with some of the new CSS3 properties; this time we’re going to detect support for the new HTML5 input types.
We need to detect whether the browser supports the new HTML5 input types natively – if not, we can use this knowledge to fall back to JavaScript where appropriate. It is important to note that there currently isn’t a lot of browser support for these input types: Opera 10.6 has the most complete support, Safari 5 and Chrome 5 have partial support, Firefox 3.6.8 and IE8 (as usual) are dead in the water. If you’re dabbling with HTML5 at all, you’ll know that support is patchy at best, and you should treat tutorials like this one as instructional rather than definitive. So whilst this information is current now, the specification is still undergoing revision (and will be for a while yet!).
Support Detection
If a browser doesn’t support a particular attribute value, it will degrade to the default value text. In theory, this is how we test for browser support – we create a new input element in JavaScript (in memory only, don’t append it to the DOM), assign to it the attribute value we want to detect support for, and then query the element’s type attribute. If the attribute retains the value that you assigned to it, the browser supports it. Otherwise, if it returns the default value, the browser doesn’t support it. Using this method, we can loop through all the new input types and log the results to console to see what we get back:
var inputs = ['search', 'tel', 'url', 'email', 'datetime', 'date', 'month', 'week', 'time', 'datetime-local', 'number', 'color', 'range'],
len = inputs.length;
for (var i = 0; i < len; i++) {
var input = document.createElement('input');
input.setAttribute('type', inputs[i]);
console.log(inputs[i] + ' -> ' + input.type);
}Notice that I began the above statement with the qualifier “in theory.” Whilst this method should technically work, some browsers are prone to giving false positives, i.e. asserting that they support a particular input type, when in reality, they don’t. Take a look at the output produced for the basic test above:
Only Firefox, IE8 and Opera are telling the truth! If you visually check in Safari and Chrome whether the UI improvements or validation functionality is present (using Mike Taylor’s HTML5 Input form, for example), it’s pretty evident that Safari and Chrome are not being entirely honest with us. So how do we test for support if two of the major browsers are telling porkies? Well, you have to go a step further and test for both UI improvements and validation functionality manually.
However, support for data validation is currently pretty flakey – that’s interpreting it generously. It appears that some browsers validate the data properly, whilst others don’t check the data but pass it as valid anyway (see this discussion for details). This probably won’t be resolved for a long time, so we’re going to validate data with JavaScript – experiments are one thing, but the state of implementation is so fragmented at this point that it’s not actually of any use to us. So in the next part of this tutorial, validation will be handled by JavaScript exclusively. What about the UI improvements? If the UI improvements are supported, we’ll use those, otherwise we’ll provide the functionality ourselves. Sounds like a plan!
We need to test for these UI improvements to see if they’re present in the browser. UI improvements can be best described as things that we’d usually have to implement a widget for in 
JavaScript – like a date picker or calendar – except now they’re implemented by the browser. We test for them by passing a text value to our mock-input, and then checking what gets returned – any new UI functionality shouldn’t be able to hold a text value. If a string is returned, there’s no UI improvement; if anything else is returned (e.g. a numerical value in the case of range, or an empty value in most other cases) then a UI improvement is present. One caveat: there are no detectable improvements or validation where the telephone and search inputs are concerned as yet, so we have to eliminate these from the first part of the test.
var inputs = ['search', 'tel', 'url', 'email', 'datetime', 'date', 'month', 'week', 'time', 'datetime-local', 'number', 'color', 'range'],
len = inputs.length,
uiSupport = [];
for (var i = 0; i < len; i++) {
var input = document.createElement('input');
input.setAttribute('type', inputs[i]);
var notText = input.type !== 'text';
if (notText && input.type !== 'search' && input.type !== 'tel') {
input.value = 'testing';
if (input.value !== 'testing') {
console.log(input.type);
}
}
}In the FF and IE consoles, we don’t get any data returned, as expected. Safari and Chrome return a non-string value for range only. Opera returns a non-string value for datetime, date, month, week, time, datetime-local, number and range. The last thing we have to do is store this information in an array so that we can refer to it later, then wrap the whole code block in a function so that the variables have some semblance of a namespace.
(function() {
var inputs = ['search', 'tel', 'url', 'email', 'datetime', 'date', 'month', 'week', 'time', 'datetime-local', 'number', 'color', 'range'],
len = inputs.length,
uiSupport = [];
for (var i = 0; i < len; i++) {
var input = document.createElement('input');
input.setAttribute('type', inputs[i]);
var notText = input.type !== 'text';
if (notText && input.type !== 'search' && input.type !== 'tel') {
input.value = 'testing';
if (input.value !== 'testing') {
uiSupport.push(input.type);
// console.log(uiSupport);
}
}
}
})();uiSupport will store the names of the input type attributes that are supported, so we can use them when we come to create our fallbacks in the next tutorial.
Quick Tip: If you need to detect support for some of the other input attributes – autofocus, for example, or any of the other new HTML5 elements, it’s definately worth checking out Modernizr. Modernizr has the added benefit of having IE support baked in, so there’s no need to include an additional HTML5 shim to get the new (header, section, etc.) tags working.