It would lead to unseasonal arguments to discuss the title of this piece here, and the arguments are as indigestible as the fourth turkey curry of the season, so we’ll restrict our article to the practical rather than the philosophical: what HTML5 can you reasonably expect to be able to use reliably cross-browser in the early months of 2010?
The answer is that you can use more than you might think, due to the seasonal tinsel of feature-detection and using the sparkly pixie-dust of IE-only VML (but used in a way that won’t damage your Elf).
Canvas
canvas is a 2D drawing API that defines a blank area of the screen of arbitrary size, and allows you to draw on it using JavaScript. The pictures can be animated, such as in this canvas mashup of Wolfenstein 3D and Flickr. (The difference between canvas and SVG is that SVG uses vector graphics, so is infinitely scalable. It also keeps a DOM, whereas canvas is just pixels so you have to do all your own book-keeping yourself in JavaScript if you want to know where aliens are on screen, or do collision detection.)
Previously, you needed to do this using Adobe Flash or Java applets, requiring plugins and potentially compromising keyboard accessibility. Canvas drawing is supported now in Opera, Safari, Chrome and Firefox. The reindeer in the corner is, of course, Internet Explorer, which currently has zero support for canvas (or SVG, come to that).
Now, don’t pull a face like all you’ve found in your Yuletide stocking is a mouldy satsuma and a couple of nuts—that’s not the end of the story. Canvas was originally an Apple proprietary technology, and Internet Explorer had a similar one called Vector Markup Language which was submitted to the W3C for standardisation in 1998 but which, unlike canvas, was not blessed with retrospective standardisation.
What you need, then, is some way for Internet Explorer to translate canvas to VML on-the-fly, while leaving the other, more standards-compliant browsers to use the HTML5. And such a way exists—it’s a JavaScript library called excanvas. It’s downloadable from http://code.google.com/p/explorercanvas/ and it’s simple to include it via a conditional comment in the head for IE:
<!--[if IE]>
<script src="excanvas.js"></script>
<![endif]-->
Simply include this, and your canvas will be natively supported in the modern browsers (and the library won’t even be downloaded) whereas IE will suddenly render your canvas using its own VML engine. Be sure, however, to check it carefully, as the IE JavaScript engine isn’t so fast and you’ll need to be sure that performance isn’t too degraded to use.
Forms
Since the beginning of the Web, developers have been coding forms, and then writing JavaScript to check whether an input is a correctly formed email address, URL, credit card number or conforms to some other pattern. The cumulative labour of the world’s developers over the last 15 years makes whizzing round in a sleigh and delivering presents seem like popping to the corner shop in comparison.
With HTML5, that’s all about to change. As Yaili began to explore on Day 3, a host of new attributes to the input element provide built-in validation for email address formats (input type=email), URLs (input type=url), any pattern that can be expressed with a JavaScript-syntax regex (pattern="[0-9][A-Z]{3}") and the like. New attributes such as required, autofocus, input type=number min=3 max=50 remove much of the tedious JavaScript from form validation.
Other, really exciting input types are available (see all input types). The datalist is reminiscent of a select box, but allows the user to enter their own text if they don’t want to choose one of the pre-defined options. input type=range is rendered as a slider, while input type=date pops up a date picker, all natively in the browser with no JavaScript required at all.
Currently, support is most complete in an experimental implementation in Opera and a number of the new attributes in Webkit-based browsers. But don’t let that stop you! The clever thing about the specification of the new Web Forms is that all the new input types are attributes (rather than elements). input defaults to input type=text, so if a browser doesn’t understand a new HTML5 type, it gracefully degrades to a plain text input.
So where does that leave validation in those browsers that don’t support Web Forms? 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. To detect whether (say) 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 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 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 branch to your old validation routines. Alternatively, use the small (7K) Modernizr library which will do this work for you and give you JavaScript booleans like Modernizr.inputtypes[email] set to true or false.
So what does this buy you? Well, first and foremost, you’re future-proofing your code for that time when all browsers support these hugely useful additions to forms. Secondly, you buy a usability and accessibility win. Although it’s tempting to style the stuffing out of your form fields (which can, incidentally, lead to madness), whatever your branding people say, it’s better to leave forms as close to the browser defaults as possible. A browser’s slider and date pickers will be the same across different sites, making it much more comprehensible to users. And, by using native controls rather than faking sliders and date pickers with JavaScript, your forms are much more likely to be accessible to users of assistive technology.
HTML5 DOCTYPE
You can use the new DOCTYPE !doctype html now and – hey presto – you’re writing HTML5, as it’s pretty much a superset of HTML4. There are some useful advantages to doing this. The first is that the HTML5 validator (I use http://html5.validator.nu) also validates ARIA information, whereas the HTML4 validator doesn’t, as ARIA is a new spec developed after HTML4. (Actually, it’s more accurate to say that it doesn’t validate your ARIA attributes, but it doesn’t automatically report them as an error.)
Another advantage is that HTML5 allows tabindex as a global attribute (that is, on any element). Although originally designed as an accessibility bolt-on, I ordinarily advise you don’t use it; a well-structured page should provide a logical tab order through links and form fields already.
However, tabindex="-1" is a legal value in HTML5 as it allows for the element to be programmatically focussable by JavaScript. It’s also very useful for correcting a bug in Internet Explorer when used with a keyboard; in-page links go nowhere if the destination doesn’t have a proprietary property called hasLayout set or a tabindex of -1.
So, whether it is the tool of Satan or yule of Santa, HTML5 is just around the corner. Some you can use now, and by the end of 2010 I predict you’ll be able to use a whole lot more as new browser versions are released.
Comments
Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.
Got something to add? You can leave a comment below.
05/12/2009
Thanks, Bruce.
I think we are all excited about HTML5 becoming more widely used in today’s browsers. I’ve been using it quite a lot in my most recent projects and I hope others do the same.
Vote Helpful or Unhelpful
05/12/2009
Tool of Satan. CASE CLOSED.
Great article, Bruce. ;)
Vote Helpful or Unhelpful
05/12/2009
Isn’t HTML5 still a working draft? It even states in the spec that “Implementors should be aware that this specification is not stable”. Do we really know that some of it is safe to use already?
Vote Helpful or Unhelpful
05/12/2009
Great stuff, I’ve been writing HTML5 for some time now, but not with the added form support, will have to look into that when coding GUIs.
Though, I would enjoy making the sliders and datepickers match the look and feel of the design – is it possible to override the browsers default styling?
Vote Helpful or Unhelpful
05/12/2009
The only thing i’m wodering is why this website scrolls so slow in Google Chrome an d not in IE and FF?
Vote Helpful or Unhelpful
05/12/2009
Marco – that’s due to a bug in Google Chrome.
Vote Helpful or Unhelpful
05/12/2009
Which is a shame as I recently started using Chrome for everything.
Drew: Is it an RGBA thing?
Vote Helpful or Unhelpful
05/12/2009
I believe it is an RGBA thing, but it’s recent, and has already been logged as a bug. It doesn’t affect other webkit browsers, just Chrome on Windows.
The Chrome team are smart and will have it fixed in no time, I’m sure.
Vote Helpful or Unhelpful
05/12/2009
Ah cool
I’m not sure too many use Chrome on Windows anyway.
Just happens that I’m the unfortunate one ;D
Vote Helpful or Unhelpful
05/12/2009
Kari- yes, html5 is changing all the time. The canvas spec seems stable, however, as it “retrospecs” existing implementations.
The HTML5 forms were the first aspects of html5 to be specified, so it’s pretty settled (although one aspect of the spec did change after the initial Opera experimental implementation).
Tor – styling the forms is problematic at the moment. We’ll probably need new CSS pseudoelements etc (eg to target the “pointer” of a slider, for example). However, the CSS Working Group can’t specify such things until the HTML5 spec is settled.
I reiterate my advice that it’s best for usability to leave form fields as close to system defaults as possible. There is always a “dynamic tension” (= war) between branding managers and designers versus usability experts, but it helps no-one if your forms are beautiful but unusable or confusing.
Vote Helpful or Unhelpful
05/12/2009
Hi Drew,
The scrolling problem is also happening on Firefox 3/Win XP. I added a comment about it on your rgba article. Not just Chrome, I’m afraid :(
Vote Helpful or Unhelpful
05/12/2009
One of the things I am most excited about are the new form attributes that replace a lot of Javascript. I guess they also degrade graceful so we don’t have to worry about any older browsers.
But still, instead of HTML5, I’d first like full support of CSS3. If only we could have them both now, supported in every browser and all. But I guess that’ll be for IE14 or something…
Vote Helpful or Unhelpful
05/12/2009
Bruce, thanks for another great article ;)
I’ve started to use HTML5 on some projects — and it’s great, I have to say :) Thanks for all the info and HTML5 doctor :)
Vote Helpful or Unhelpful
05/12/2009
Excellent article, thanks.
Vote Helpful or Unhelpful
05/12/2009
“(Actually, it’s more accurate to say that it doesn’t validate your ARIA attributes, but it doesn’t automatically report them as an error.)”
Validator.nu does validate ARIA. If you try to do something bogus like using a property that doesn’t apply to the role used, then it’ll report an error.
Vote Helpful or Unhelpful
05/12/2009
Definitely not a tool of satan. HTML5 as new and scary as it may seem, is a huge blessing. The fact is, everything is becoming easier for us developers, and designers as well.
I also, like the backwards compatibility of it as well.
While I won’t be utilizing everything, such as canvas, it still serves as a huge step in browser development, and hopefully it will send a hint to the guys at Microsoft to start improving IE
Vote Helpful or Unhelpful
06/12/2009
I’m currently switching my doctype over to HTML5. You know it’s ok when google does it. I’m pretty excited for the day HTML5 is ratified. I’ve been using more and more CSS3 over time now and just started with a little HTML5.
Vote Helpful or Unhelpful
06/12/2009
Great article Bruce, as someone who has changed their site to be HTML5 it’s always nice to read a little more and learn about other aspects of HTML5 that I haven’t yet used.
Thanks
Vote Helpful or Unhelpful
06/12/2009
zcorpan – wow, when did that happen? I didn’t know! Thanks for telling me; I’ll amend the article.
Vote Helpful or Unhelpful
06/12/2009
It happened when Henri first implemented ARIA support. :-)
See http://hsivonen.iki.fi/aria-html5-bis/ for details, although I think Henri has updated the implementation since that was written (for instance landmarks are now supported, IIRC).
Vote Helpful or Unhelpful
07/12/2009
I wonder how useful these new web input controls will actually be.
How will an error be visually displayed to a user when a particular regex is false or when a field doesn’t represent an email?
Equally how will a successful field entry be displayed to the user if required i.e. on blur of a field display a green tick? If we do this with custom JS, then we will have to be able to test the field to see if it’s valid. In which case how much value are these new attributes?
With errors usually you will want to add a class of “error” in order to do some sort of styling. Or you may want to add some HTML that displays a description of the error. This functionality is usually quite custom per project.
What happens if the date picker is quite “basic” compared to other JavaScript components/plugins on the web?
To acheive this sort of thing you may need something yucky like:
<input type=“email” onerror=“myFunc” onsuccess=“myOtherFunc” />
Hopefully I am lacking so much knowledge on this that all my concerns are silly.
Cheers
Adam
Vote Helpful or Unhelpful
08/12/2009
Ok, to answer my own fears somewhat I have been reading
http://dev.w3.org/html5/spec/Overview.html#the-constraint-validation-api
There are a bunch of methods and properties that can be checked against a field in JavaScript to test whether something is valid or not etc.
However this level of basic input validation doesn’t really cater for a lot of the needs of a website with something more than a tiny contact form or a comments form such as the one I am writing in for this.
There are further levels than just required/min-length/max-length/regex.
Sometimes you may want to do cross field validation i.e. “when a particular field is checked then another field should be mandatory”.
In short, I think a lot of the improvements being made to form fields might end up not being as useful as some may think.
What really works in the HTML4 input spec/behaviour is that only the maxlength is provided as an attribute and that works because the user is forced not to type something bad – it is impossible, therefore an error can never occur with regards to that validation rule. The really bespoke stuff can be written by the developer.
I am not sure what the best way forward is but I have developed the JS form validation frameworks for many different clients and taken advice on certain aspects by the RNIB. Whilst being able to apply powerful client-side validation is always the same, the visual output can be very different.
These extra properties and methods only cater for some very basic validation rules. I would have to integrate a branch of validation for the native api and a branch for the custom api (which I create in my js validation framework)
Vote Helpful or Unhelpful
08/12/2009
All good points, Adam. And you’re right – built-in validation doesn’t cover every conceivable use case. It isn’t designed to; HTML5 makes unabashed use of the 80/20 rule.
So, consider this comment form; it has three required fields (name, email, message). One is input type=email, one is email type=url. Those are all taken care of by the new form types. I would be willing to bet that the “comment form”/ contact us form already makes up the majority of web forms.
Additionally, with built-on date pickers, pattern validation (think customer IDs, part numbers, credit card numbers, catalogue numbers, postcodes) that comfortably gets up to 80%.
The spec has bunch of methods and properties, as you say, that allow custom validation. It has nothing to say about how browsers should display or style errors; that is up to browser vendors.
Vote Helpful or Unhelpful
08/12/2009
Thanks for your response Bruce.
I know what you are saying about the 80-20 rule but I guess in my world, there are a lot of forms that require more advanced features. – let’s say registration, returns process, checkout process, manage multiple addresses and payment details in the account areas etc.
Also, on your point of the browser vendors coming up with styling of errors. That causes another issue. What if the project requirements for whatever reason (opinion, accessibility, usability) contradict what the browser vendor decides to implement?
What if for example the browser puts a red border around the erroneous input in question but I want a red exclamaton icon as a bg to the associated label with a little more padding? We would seem to have two branches of visual errors – the way the browser deems it and the way the project requirements deem it?
I like the idea of standardising these features but I see a lot of issues with it.
And putting a pattern attribute on an input is mixing behaviour/business-logic/js layer with the content/mark-up/html layer – although this is a picky point, i think it is valid.
Vote Helpful or Unhelpful
08/12/2009
Adam,
I expect form errors to be stylable. It probably needs the CSS Working Group to conjure up more pseudoelements/ classes and they’re unlikely to want to do that while the HTML5 spec is still moving.
I re-reiterate my advice r/e styling forms:
“it’s best for usability to leave form fields as close to system defaults as possible. There is always a “dynamic tension†(= war) between branding managers and designers versus usability experts, but it helps no-one if your forms are beautiful but unusable or confusing.”
Vote Helpful or Unhelpful
08/12/2009
Bruce,
Thank you again for the response to my comments.
I agree about your points on usability, and keeping to system defaults.
I guess it will be interesting to see what happens later once specs are finalised and browser vendors implement them.
Vote Helpful or Unhelpful
09/12/2009
Bruce, thanks for tip on ‘excanvas.js’ – I was not aware that such a script was available. I’m very interested in utilizing canvas. I also found it very interesting about your observation that form controls should be kept as close to browser defaults as possible. Although I agree, is there any research/data analysis that supports this.
Vote Helpful or Unhelpful
09/12/2009
Anthony
I read some research a while ago (spool? Wrobeleski?) but can’t find it now.
But other research backs up the idea of not mucking around with user’s expectations, so if – for example – a dropdown looks like this in Mac, it probably looks the same in Safari and therefore the user will understand a system control more readily than something else made with JavaScript simply because it conforms to a designers’ whim.
Vote Helpful or Unhelpful
14/12/2009
Its slightly satanesque in that people might be tempted into overusing the 3D api etc. Its a flashback to the days of maquees flashing text and animated gifs. I’m just wondering how smoothly the whole HTML5 thing will integrate hehe
Vote Helpful or Unhelpful
16/12/2009
About field validation, if the browser is not modern then leave it just like that and use the back end validation instead (there is always going to be back end field validation either way…)
Vote Helpful or Unhelpful
24/12/2009
Nice Article! Once again I enjoyed reading this one.
I’ve been writing HTML5 for my last 5 projects and I’m including the newly added form support.
Some of my fellow colleagues think I’m a bit mad and “jumping before the gun” but I believe different… I think there is no problem with including the HTML5 bells and whistles in your work now!
Sean
Vote Helpful or Unhelpful
05/01/2010
The article makes no mention of the use of the HTML 5 enabling script. http://remysharp.com/2009/01/07/html5-enabling-script/ Is this still required for styling HTML5 (only) elements in IE? Is this functionality already included in the Modernizr and/or explorercanvas script?
Also, I am curious why the author does not make use of new html5 elements on this blog?
Thank you for informative article :-).
Vote Helpful or Unhelpful
14/01/2010
Paul
I make no mention of the “IE-enabling script” as the article doesn’t mention using any of the HTML5 structural tags, so there is no need to discuss how to style them.
A glance at the Modernizr website tells me (and you) “Modernizr also enables you to use more semantic elements from the HTML5 spec, even in Internet Explorer. See the documentation for details.”
I don’t know why Drew, who runs this site, doesn’t use HTML5. I’m an invited author and have no control over the markup.
Glad you found it informative.
Vote Helpful or Unhelpful
Impress us