However, all the content is still readable/searchable so it depends how they want it to look without javascript.

Isn’t that a bit of a contradiction? How can you be a lover of HTML and not like the fact tags are case-insensitive, etc? If you had said you were a lover of XML it would make more sense. ;)

But for me that is the great thing about how they are specing HTML5. They’ve done away with (for the most part) arbitrary rules for the sake of having rules and instead are looking at how HTML is being used in the real-world and attempting to bring the spec inline with use.

I don’t think I’ll ever be able to write an input without closing it or write my tags in ‘shouty’ UPPERCASE. But I don’t have to I can keep writing it the way I like to, using XHTML syntax (though I do like the idea of doing <input type=’text’ autofocus />)

http://www.w3.org/WAI/intro/aria

I have started using HTML5 on all new projects now – granted, it’s mostly just the doctype at the moment and a few elements that fallback to sensible defaults (like the time element or new input types), but as support becomes more widespread I’ll slowly introduce more and more new pieces.

I’m with you with regards to commercial work – although I am throwing in the odd thing (doctype being a prime example of this).

I love early adopters and their willingness to work through the teething troubles of new standards and technologies but I wont be one this time round (on client work at least).

I was an early adopter when people were switching from tables to CSS layouts some years back but there was a clear benefit of CSS over tables where as for HTML5 I don’t feel there is that clear discernible benefit I can explain so easily to a client that will justify the following likely head aches that come with doing some “bleeding edge”.

I’ve learnt the hard way in the past that doing the bleeding edge thing is not always best for you or your client here are just a few of the head aches I can think of:

* In-house staff are most likley going to be unfamiliar with and confused by it.
* Existing CMS’s/WYSIWYG’s,Scripts,etc are likely to mess things up and/or cause annoyance by by malforming code, etc.
* It will take you more time to write and document.

I’m sure many will make the point about how we’ve all been using CSS 2.1 for years despite the fact that it only become a candidate recommendation in 2009 and its a fair point but that was presentational not structural for a start and people did what I’m going to do this time round and didn’t jump in with two feet, they gradually moved over to tableless layout and no presentational mark up.

A nice quote I saw picked out was:

“Implementations and specifications have to do a delicate dance together. You don’t want implementations to happen before the specification is finished, because people start depending on the details of implementations and that constrains the specification. However, you also don’t want the specification to be finished before there are implementations and author experience with those implementations, because you need the feedback. There is unavoidable tension here, but we just have to muddle on through.”

I going to muddle on through on my personal work and on Airfront’s new site but for client work I will be taking a step back until I’m sure its right to do so, which I think is part of the fun. I’m keen to play and experiment on my personal sites so it will in a couple of years time inform my professional work which is how I think most of us learnt anyway.