Tool of Satan. CASE CLOSED.

Great article, Bruce. ;)

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

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.

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?

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?

The only thing i’m wodering is why this website scrolls so slow in Google Chrome an d not in IE and FF?

Marco – that’s due to a bug in Google Chrome.

Which is a shame as I recently started using Chrome for everything.

Drew: Is it an RGBA thing?

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.

Ah cool

I’m not sure too many use Chrome on Windows anyway.

Just happens that I’m the unfortunate one ;D

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.

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 :(

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…

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 :)

Excellent article, thanks.

“(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.

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

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.

zcorpan – wow, when did that happen? I didn’t know! Thanks for telling me; I’ll amend the article.

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).

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

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)

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.

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.

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.”

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.

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.

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.

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

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…)

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

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 :-).