I’ve recently been doing a lot of digging into quote/unquote “newer” browser capabilities, some of which are very cool. I will share what I’ve discovered as I go.

As always I’m using a little “test project” as my sandbox, this is a real-world website that’ll use all these features and I’ll share that when it’s done.  So far I’m using oAuth/Twitter integration, ASP.NET MVC/JQuery as a basic stack and am adding in HTML5 and CSS3 features. The resulting site will not be pretty but the point for me is always to get more exposure than having just read the brochure.

This time around the topic is form controls.

I hate forms, they are so boring and my luddite brain can never seem to figure out how to lay them out properly. There is nothing interesting about forms, what could HTML5 possibly bring to the equation?

I was pleasantly surprised; HTML5 under “Web Forms 2.0″ adds a bunch of new form input types. In HTML4 you have

<input type="text" id="someText" />

In HTML5 you can actually specify the type with a bit more semantics, e.g. “tel” for telephone or “number” for integers and the browser will apply some basic masking to the field.

Number and Date types are fairly typical but I was surprised how specific these get, e.g. “type=color”, “type=url” and “type=search”.

Another interesting one is “type=range” which allows a text field to be accessed via a little slider control. Before I would’ve had to implement something like a JQueryUI Slider, now the browser will handle this for me natively. Here’s an example:

</div>
<div><input type="range" min="10" max="90" /></div>
<div id="_mcePaste">

In addition to new input types there are also new attributes which will further reduce the amount of client-side javascript needed for forms. E.g. the  “required” and “autofocus” attributes do as their names imply. This is where CSS3 comes in with its pseudo-classes. E.g. input fields now have a pseudoclass called “valid” and “invalid”.  I can style these like this:

input:valid {
background-color: red;
}

input:invalid {
background-color: red;
}

When a field tagged with “required” but it’s empty, the browser *should* assign this pseudo-class and render it accordingly. Hey, that’s saving me some more boiler-plate Javascript.

Some interesting ones though are “min” and “max”, e.g. when applied to a “type=number” or “range” will determine the limiting values for the control. Excellent.

I’ve looked at the spec ( http://www.whatwg.org/specs/web-apps/current-work/ ) and do have some questions still such as how to localize things like the telephone field masks? I’m sure we’ll see some more on this in the future.

Besides simpler coding, these new semantics should also improve accessibility. Things like JAWS can now distinguish required fields from the DOM and determine that field A is an email vs field B being a search box.

This is all fairly new so the specifics of what each browser does will likely flex a bit until fully bedded down, most of these don’t do anything (yet). At least the markup is there now and I’m liking where this is headed.

Here’s a simple test page I came across for reference: http://miketaylr.com/code/input-type-attr.html

As always you can check with http://caniuse.com for a detailed rundown of who’s supporting what.  (Opera’s had this stuff for quite a while now).