How to use HTML5 in your client work right now

by .

I was presenting some designs to a client a couple of weeks ago when this question came up: Will you be building this site with HTML5 in mind? Naturally, I was happy to answer that one! It went a little like this:


We’ll build the whole thing with HTML5 if that’s okay with you guys. One question though: do you know what percentage of your visitors use Internet Explorer without JavaScript to view your site?


Erm, I don’t really know, and I wouldn’t want to lose those visitors. Maybe we’d better not build it in HTML5 after all.


Whoa there! No need to be so hasty. We don’t have to use HTML5 exclusively, but we can still use it to develop specific parts of the site. How does that sound?


Great! Let’s do it!

After telling Remy about this conversation, he proposed that we cover this subject in an article, so here we are!

We’re treating this article a bit differently, like a Q & A with the authors, so let us know if you like this new style.

Which bits of HTML5 can I use right now?

Rich: Lots of them! Here’s a short list of cross-browser (including IE) compatible techniques that you can use today:

For a clearer idea of what is or isn’t cross-browser compatible, check out these sites from Molly Holzschlag and Alex Deveria.

Remy: Assess the technology and fit it to your project. If I have a lot of IE6 users, I avoid using PNGs. If I have a lot of IE users with JavaScript disabled, I give them reduced markup as Rich pointed out earlier (e.g., simplified doctype, <script>, and <style> elements) but avoid using new block-level elements like <section>. If they have a very interactive product that relies on JavaScript anyway, I don’t have any qualms using JavaScript to help IE style the new elements.

Also, I’m going to detect Web Forms 2.0 and other HTML5-type support using something like Modernizr, and then fall back on “traditional” JavaScript for things like date pickers if they’re not available natively.

What are the benefits of using HTML5 now?

Rich: Here are several, in no particular order:

  • Cleaner markup
  • Additional semantics of new elements like <header>, <nav>, and <time>
  • New form input types and attributes that will (and in Opera’s case, do) take the hassle out of scripting forms
  • Staying ahead of the curve before HTML5 becomes the mainstream markup language. Use this as a selling point when talking with your clients

What are the downsides to using HTML5 now?

Rich: Obviously, you make some trade-offs when using HTML5:

  • The spec isn’t finished and is likely to change
  • Not everything works in every browser (but you could say the same about CSS, right?)

Should I tell my clients I’m using HTML5?

Remy: No. When I go to buy a car, I don’t ask about the parts in the engine. I just want to know what it looks like, how much it costs, its level of quality, features, etc. Sure, some people are mechanics, but most aren’t.

Clients aren’t developers, so they shouldn’t influence your decision on what technology to use. When they ask What technology are you going to use? or Should we be using HTML5?, we, as developers, should tell them:

It depends on your product and your audience. Do you have any usage statistics that I can see?

Rich: Yes, you should. If a client doesn’t want to use HTML5 for a project, simply explain the benefits mentioned above. Point out that their site will be built using an up-to-date markup language, so it’s less likely to need updating in a few years. It’s “future-proofed”, and it will save them money in the long run.

What if my client mentions that “HTML5 won’t be finished until 2022”?

Rich: Politely inform them that it’ll be closer to 2012 (and some might argue even sooner). Tell them you’re building this site with an eye on the future and that it will help them in the long run. In my opinion, it’s only fair to inform your client that you’re using HTML5 (depending on their position and level of understanding), though in some cases it won’t matter because they’re only concerned with how the site looks in the browser they use.

Remy: My opinion is that you shouldn’t be discussing with the client which technology to use — only (perhaps) providing justification as to why you’ve used a particular technology. You can assure them that SEO and compatibility won’t suffer, but just as you don’t offer accessibility as an optional item on the menu (well, I certainly hope you don’t), you shouldn’t offer HTML4, XHTML, or HTML5 as a menu item either.

Will using HTML5 negatively affect my clients’ search engine rankings?

Rich: No. Google is properly indexing sites built with HTML5. Take our site for example — it’s doing just fine. ;)

Have you built any client sites with HTML5?

Rich & Remy: We’ve both started using things like the simplified doctype and reduced markup in our client work. We’ve also used HTML5 on a lot of professional projects where we’re our own clients, such as Speak the Web and the 2009 Full Frontal JavaScript Conference.

We haven’t used it as much for full-fledged HTML5 apps that use all the new markup and new APIs – but rest assured, there is work in the pipeline. :)

Rich: I’ve also recently released an events site for the agency I work for that uses new HTML5 elements.

So should I be using HTML5 in my projects right now?

Well, as with all projects, it depends on the client (are they marketing directors or IT directors? internal or external?), the budget, and the timescale, among many other things.

To wrap up, we’ll leave you with our checklist for building client sites with HTML5:

  • Use the HTML5 doctype and character set.
  • Use the simplified <script> and <style> elements.
  • Use semantic class names that are representative of the new HTML5 elements. See @boblet‘s cheat sheet for more on this.
  • Use block level links.
  • Use the new form attributes and input types.
  • Use the new <audio> and <video> media elements (but make sure they degrade gracefully).
  • Plug the gaps with something like Modernizr.

If you think there’s anything more that we could be doing today, please let us know. I’m also keen to find out who is using HTML5 on client sites today. I’ve seen quite a few on the gallery, but it would be great to hear some arguments for and against building clients’ sites with HTML5 now.

63 Responses on the article “How to use HTML5 in your client work right now”

Leandro (inkel) says

Use semantic class names that are representative of the new HTML5 elements. See @boblet’s cheat sheet for more on this.

Would it be way much more easier to link the cheat sheet, I think.

Mathias Bynens says

It should be noted that sadly, it’s impossible to style HTML5 elements for print media in IE. The HTML5 enabling shim/shiv won’t work, since JS is not processed when printing. To me, this is the only reason not to use HTML5 for client sites sometimes.

BWRic says

I think it’ll be about 2022 until any of my clients realise HTML even exists, and there is life beyond IE6. I’m tempted to give it a go though, been using it for a few months for a Content Management System as that allows me to demand stricter requirements. As you mention it’s all about the audience of the site at the moment and whether it’ll effect them.

Leandro (inkel) says

@Richard thanks for the link.

Remy Sharp says

@Mathias – you’re of course right about the shiv, but I’d quite happily argue that printed sites, in nearly all cases, shouldn’t look the same as the web page. They’re two completely different mediums. For example sidebars don’t work in print (when the item is a web site, whereas they do work in newsletters, but newsletters don’t work as web pages) – so it’s a case of creative thinking. I think there’s a lot more that can be discussed about that topic.

That all said, the page will print just fine using IE6 the HTML5 doctype and no type attribute on the script elements, which is the starting point (for me and others) for HTML5 web pages.

Adam Harvey says

I liked this format a lot. Thanks for the article.

Ben Atkin says

Good article. I’m sure this strategy could be used to get NoSQL into use as well. Some clients or bosses might not be so quick to get it, after you tell them that the new technology can co-exist with what’s already in use, but I think most should come around when you explain the benefits to them, and explain who else is using the new technology.

Dean Edwards says

If you know how to disable JavaScript then you know how to download Firefox.

Dan M says

Great post! I haven’t managed to get any HTML5 work yet (I’m a software developer) but I am starting to have conversations with stakeholders about HTML5 as an option, especially on mobile devices where there aren’t problems like old versions of IE.

@Dean: I totally agree; I’m going to start quoting that :)

John Faulds says

I’ve been doing pretty much all of the suggestions for a while now except for using block level links and the new and media elements (as I rarely work with them anyway) and using Modernizr. I don’t really see the point of Modernizr too much at the moment: most CSS3 you can use safe in the knowledge that if a browser doesn’t understand it, it’ll just leave it out and it won’t affect the page presentation.

Oli Studholme says

@Leandro (inkel), @Rich — I need to update that article and add more ARIA roles to it, as it’s definitely out of date now (although hopefully still a good starting point). Once I’ve updated it I’ll post here.

The most important idea here is using HTML5 is a sliding scale, not all or nothing — you can get benefits from simply changing the doctype (a better validator and a far more detailed spec), and that’s a five second job.

Title: « Elite Path says

[…] How to use HTML5 in your client work right now | HTML5 Doctor […]

Mathias Bynens says


If you know how to disable JavaScript then you know how to download Firefox.

That may be so, but if your sysadmin is the one doing the disabling, that statement just won’t fly.

Zak Adelman says

If the sysadmin is doing it then the sysadmin can answer to the enduser why sites don’t work… HTML5 or not. Besides sysadmins who are not completely incompetent would download FireFox at least as an alternative ay way.

Jason says

Great article. I just launched a client site that uses the simplified DOCTYPE and a few HTML5 tags. Works great across browsers and the client notices nothing.

I didn’t mention HTML5 to them, just because they were a very non-tech client group.

pengkai says

yep.I wanna to rebulid my blog using HTML5

Dean Edwards says

Companies that still use MSIE have usually invested in intranet apps that use JScript. I doubt that they will disable JS.

manuel says

@Dean Edwards, with my (much due) respect, that sounds like an ad-hoc fact to me. JS can be off due to proxies, domain policies, and whatnot. I’m making this up, but I can imagine an intranet using IE-only JS, and a proxy removing all scripts “for security”.
Or does someone have actual stats on this?

Jason says

What about the new tag, I’m really interested in this as I hate the bulky Flash/QT stuff there now… Have you guys seen this working?

Jonathan Neal says

I’ve come up with a solution for printing @ IE Print Protector. Remy Sharp plans to add this into his popular shim/shiv. AlloyUI is already adding it, and one of the guys from Modernizr said it will probably make it in.

So, one less excuse. =)

Rich Clark says

@Jonathan, I spotted that last week, cracking solution. Looking forward to it being baked into the shiv and Modernizr, good work!

Ben says

Can the new HTML 5 markup be used when designing WordPress themes?

Jason Rhodes says

@Ben — you certainly can use some of it, just like you would anywhere else. I’m using the DOCTYPE and some semantic elements in my WordPress themes. is built in WordPress, and if you view source you’ll see article, section, and other various HTML5 elements used, so I can use H1 tags in all of my subsections.

I love it.

Someone says

Its all very cool with HTML5… it looks like this is going to be IT.

But tell me. In Adobe Flash you got a socket, which allows you to connect to a ip and a port. And remain connected until you use the .close (to close the connection again)
Which allows you to open up a connection in realtime from your website to your server, and use the senddata, and dataarrival to send and receive data from the website with your server(s).

In HTML this will not going to happen i think.
XML is a nice feature. But it doenst remain the connection open. After the GET is completed the connection will be closed. So if you want to refresh Some part again in full real-time you need endless of GET Statements if the data is changing every couple milliseconds.
With Flash you could simple use the .senddata method. No need to re-connect all the time from client to server.

Now. How is HTML5 going to fix that? – Flash allows us to use a socket in adobe flashbuilder (flash)

Flash will be here for a Long, Long time.
Althought i dont like flash to work with compared to HTML + javascript. But sometimes you need it. Period. And then even HTML will not gonna help you (think about a webcam system on a website, you gonna do that in html5?)

And that is what websites need these days. Full realtime information without no slow XML requests all the time.
So until that is ever going to happen Adobe Flash(r) will be used (think about webcam systems where you need to broadcast realtime video, you wanna do that with the or the XML get statement…. trust me, that will fail soooo badly)
And also think about VISTA when you do your statements about Adobe Flash being slow.
First Adobe NEEDED to include Everything to their ‘language’… but that takes time. they have to catch up with microsoft and the other standards.
With the newer and newer versions of Adobe they just trying to speed it up. And THAT will take another couple years.
Its just the same as with HTML5 not finished to give us all our needs that we need TODAY.

Im a Microsoft Certified Solution Developer (from the age of 18 already)

Good luck, and happy programming.

The road has already been layed down long time ago. Dont try to fight it, but use it, or end up at the Linux community complainers.

Someone says

If that is the sockets so that we can use it straight in javascript, then this HTML5 got quite some potential above flash sockets. Hopefully it works out, so far i hear good things about html5, and im not a grandpa who likes to stay behind. Hope to see this more and more.
Cause i do like html+javascript above that adobe flashbuilder. But if a task cant be done your out of options… But if HTML5 is going to allow the sockets just like its telling its going to do. Then im happy to see forwards to it.
Thanks for the info. And keep up the good work.

Someone says

see. it all is possible, websites will be very cool.
Althought i will like to see how html5 sockets are going to work with binary data (null chars).
Cause in some cases you need that. For example for a picture stream.
In flash you can use the writebytes to a picture, and show the picture on the screen.
But im quite sure in html5 this is going to have some issues, because in html you cannot use binary data and write it just to the screen. (to save disc activity)
Flash(r) has some nice features that i hope to see also in HTML. But the info you gave looks a good start already to gather info.
Happy programming all.

Cybernoxa says

I think the final checklist should be more hardcore and backward compatible:
* Change your doctype – Use the HTML5 doctype.
* Simplify your character set – use HTML5 character set
* Simplify your <script> and <style> elements
* Get into the habit of using HTML5 class names in your HTML4/XHTML1 markup – Use semantic
* class names that are representative of the new HTML5 elements, use new HTML5 inline elements such as <time> (where possible without styling them) to add semantics that will be interpreted by leading browsers
* Use new HTML5 attributes and avoid using deprecated ones like cellspacing & cellpadding
* Plug the gaps with something like Modernizr.
* Should not: Use block level linking
Should not: Use the new form input types, as they degrade gracefully
Should not: Use the <video> and <audio> elements, and then make them degrade gracefully

shulato says

great article, i’m new to html 5. so if i change the doctype i’m already using html 5? but i will still use the same tags? does changing the doctype is cross browser?

Rich Clark says

@shulato – Yes changing the doctype works cross browser, it is the shortest string to trigger standards mode.

MindSculpt says

This article is a great reference for anyone’s peers, bosses or clients worried about implementing HTML5 features when they are still developing for IE6. Good stuff.

Andy's sketchbook says

[…] experts have been telling us to dive in for a […]

Anonymous Coder says

HTML 4.01 Strict FTW.

The Story of the HTML5 Shiv « Paul Irish says

[…] 2010: Mathias Bynens and others notice the shiv doesn't affect pages printed from IE. It was a sad day. I issue an informal challenge to developers to find a […]

Is Your Client Unsure of HTML5? | HTML5 Camp says

[…] various cloud service options that can be used. This article explains and lists the reasons why HTML5 may work for devloping your client's website and the beneficial practicalities of HTML5. Your best bet is to assess the technology and fit to […]

Robert says

IE6 should be dead, as for me i don’t support it on my site, according to analytics only 4% of the users that enter my site use IE6 so im not that worried.

John says

I agree with Robert, IE6 is becoming less and less relevant with each passing day. We should all be moving forward and using HTML5 where we can.

Tobias says

Thank you for the great article. Some VERY good points to consider. I really liked the link about HTML5 video tag.

HTML5 is great, though you should really think twice or better trice to use it or not in your project.
Though some semantic tags etc I already use 100% and i guess there won’t be any troubles in the future even if the specs change

Join the discussion.

Some HTML is ok

You can use these tags:
<a href="" title="">
<abbr title="">
<blockquote cite="">
<del datetime="">
<q cite="">

You can also use <code>, and remember to use &lt; and &gt; for brackets.