A third way to write and validate forms – HTML5

After writing an accessible form in XHTML and validating it with a PHP server side script & after that with a Mootools client-side script, I write today about a third way of approaching the subject – using future-to-come HTML5 (by saying that, I really hope to be able to use it waaaay before 2011).

The beauty consists in having all the above mentioned validation inside HTML code:  we’ll have

  • input type=”email” for email addresses
  • type=”url” for urls
  • type=”date” and “datetime” for date fields (usually done with JS calendars until now), or “month”, “week”, “time”
  • type=”number”  for number only inputs
  • accessible sliders, with type=”range”
  • datalists
  • ability to add extra validation conditions after writing the tag, like: required, read-only,disabled, autofocus, a minimum value, a maximum accepted value/length

The code for our simple contact form will be much lighter:

<form action="index.php" method="post" name="contactform" id="contact">
 
<label for="name">Name <span>(required)</span></label>
<input  tabindex="1" type="text" name="name" id="name" required />
 
<label for="mail">Email <span>(required)</span></label>
<input  tabindex="2" type="email" name="mail" id="mail" required />
 
<label for="phone">Telephone</label>
<input tabindex="3" type="text" name="phone" id="phone" />
 
<label for="message">Message</label>
<textarea tabindex="4" cols="30" rows="10" name="message" id="message"></textarea>
 
<button tabindex="5" type="submit" name="submit" id="send">Submit</button>
 
</form>

The result will be a much easier way of writing and validating forms in an accessible manner, without adding extra load/code with PHP/JS scripts. All you have to do is place “required” to all the required fields and use the above mentioned minimum value, maximum accepted value, etc to control the user’s input.

The entire list of types and useful tables with the methods that apply to each state can be found on W3C site

The problem right now is the inabilityof the browsers to work with lots of HTML5 features. And the future does not look good either. So far the only browser that supports the new forms is Opera 9.5+.  Internet Explorer 8 and below is not compatible and IE9 probably won’t be either (we’re talking about 2010).  Chrome 2+, Safari 4+ will partially support some features while Mozilla won’t do it even in its 4.0 version (due to launch in 2010).

Now, the same contact form we used to play with, but written in HTML5, will look the same but behave much more nicely (the code is lighter too). It’s saving us a lot of time and headaches and it’s much more user friendly.  Play with the new example – in Opera 9.5+ – and drop us a feedback if you consider that the subject is interesting enough to come back with more code-examples.

Check the Spanish version of this post:
Una tercera manera de escribir y validar formularios – HTML5

4 thoughts on “A third way to write and validate forms – HTML5”

  1. I would love to see this fully implemented, it’s just such a shame that trying to update anything on the code end of the web is such a lengthy process… by the time this is finally approved and used across all (at whatever point in time this ends up being) modern browsers, we’ll be trying to get the new wave of tags and elements going. I know it’s been talked about and we’ve all heard both sides, but browsers and their manufacturers need a better way of releasing updates and ensuring that all of their users receive them in a timely manner so that the future of the web isn’t stuck years behind the present.

  2. Hi Jason, you are perfectly right and this is an on going fight since …well…forever, I guess. There’s no point in complaining about this, I have the feeling that MS will not listen (if they would, IE8 might have been a bit better, don’t you think?) and after I wrote this I was thinking if I should start embedding HTML5 & CSS3 in my projects – I have mixed feelings.

    Altough it would be great for me (I learn) and for some users (with better browsers – altough they will not detect the improvements at a browsing level) I still think it’s not profitable from a financial point of view. Because that means I have to spend a lot of time trying to find JS scripts that would fix the layout in older browsers. And that will be very time consuming besides the fact that my clients will not “understand” my attempt to apply new technologies in their websites. (I know I’m evil for saying that, but we do not code for free)

    And I definitely would not like to exclude IE users from browsing my sites nor do they deserve a lower browsing experience just because they are using the “bad” browser. So I think I’ll just asimiliate these news bit by bit and keep on checking my awstats to see what will happen in the next 6-12 months.

    I’m really curious what other coders think about this.

  3. It’s perfect! Exactly what I was looking for, thanks so much for making it easy to understand and use :)

    @Lucica: I think it’s important to explain to your clients briefly what’s going on with browsers and insist on how their internet navigation would be enhanced if they tried several browsers before making a final decision, I’m sure they’ll quickly adopt different browsers. I found that if people don’t know they have the choice, then they stick to what they know.

    I have the same shared feeling regarding much modern design and coding tools, so I think it depends on what you do, on your target niche: geeks or grannies (it’s a shortcut for my idea, heh, I have nothing against grannies)? Then you decide if you REALLY have to bother about IE6 fixing issues etc.

    Ultimately, you can’t please all browsers so it’s the target niche that counts :))

    I bookmark this site, I really like what’s going on here! xD

    -Laters

Comments are closed.