HTML5: The Facts And The Myths


You can’t escape it. Everyone’s talking about HTML5. it’s perhaps the most hyped technology since people started putting rounded corners on everything and using unnecessary gradients. In fact, a lot of what people call HTML5 is actually just old-fashioned DHTML or AJAX. Mixed in with all the information is a lot of misinformation, so here, JavaScript expert Remy Sharp and Opera’s Bruce Lawson look at some of the myths and sort the truth from the common misconceptions.

First, Some Facts

Once upon a time, there was a lovely language called HTML, which was so simple that writing websites with it was very easy. So, everyone did, and the Web transformed from a linked collection of physics papers to what we know and love today.

Most pages didn’t conform to the simple rules of the language (because their authors were rightly concerned more with the message than the medium), so every browser had to be forgiving with bad code and do its best to work out what its author wanted to display.

In 1999, the W3C decided to discontinue work on HTML and move the world toward XHTML. This was all good, until a few people noticed that the work to upgrade the language to XHTML2 had very little to do with the real Web. Being XML, the spec required a browser to stop rendering if it encountered an error. And because the W3C was writing a new language that was better than simple old HTML, it deprecated elements such as <img> and <a>.

A group of developers at Opera and Mozilla disagreed with this approach and presented a paper to the W3C in 20041 arguing that, “We consider Web Applications to be an important area that has not been adequately served by existing technologies… There is a rising threat of single-vendor solutions addressing this problem before jointly-developed specifications.”

The paper suggested seven design principles:

  1. Backwards compatibility, and a clear migration path.
  2. Well-defined error handling, like CSS (i.e. ignore unknown stuff and move on), compared to XML’s “draconian” error handling.
  3. Users should not be exposed to authoring errors.
  4. Practical use: every feature that goes into the Web-applications specifications must be justified by a practical use case. The reverse is not necessarily true: every use case does not necessarily warrant a new feature.
  5. Scripting is here to stay (but should be avoided where more convenient declarative mark-up can be used).
  6. Avoid device-specific profiling.
  7. Make the process open. (The Web has benefited from being developed in the open. Mailing lists, archives and draft specifications should continuously be visible to the public.)

The paper was rejected by the W3C, and so Opera and Mozilla, later joined by Apple, continued a mailing list called Web Hypertext Application Technology Working Group (WHATWG), working on their proof-of-concept specification. The spec extended HTML4 forms2, until it grew into a spec called Web Applications 1.0, under the continued editorship of Ian Hickson, who left Opera for Google.

In 2006, the W3C realized its mistake and decided to resurrect HTML, asking WHATWG for its spec to use as the basis of what is now called HTML5.

Those are the historical facts. Now, let’s look at some hysterical myths.

The Myths

“I Can’t Use HTML5 Until 2012 (or 2022)”

This is a misconception based on the projected date that HTML5 will reach the stage in the W3C process known as Candidate Recommendation (REC). The WHATWG wiki3 says this:

For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

So, by definition, the spec won’t be finished until you can use all of it, and in two browsers.

Of course, what really matters is the bits of HTML5 that are already supported in the browsers. Any list will be out of date within about a week because the browser makers are innovating so quickly. Also, much of the new functionality can be replicated with JavaScript4 in browsers that don’t yet have support. The <canvas> property is in all modern browsers and will be in Internet Explorer 9, but it can be faked in old versions of IE with the excanvas library5. The <video> and <audio> properties can be faked with Flash in old browsers.

HTML5 is designed to degrade gracefully, so with clever JavaScript and some thought, all content should be available on older browsers.

“My Browser Supports HTML5, but Yours Doesn’t”

There’s a myth that HTML5 is some monolithic, indivisible thing. It’s not. It’s a collection of features, as we’ve seen above. So, in the short term, you cannot say that a browser supports everything in the spec. And when some browser or other does, it won’t matter because we’ll all be much too excited about the next iteration of HTML by then.

What a terrible mess, you’re thinking? But consider that CSS 2.1 is not yet a finished spec, and yet we all use it each and every day. We use CSS3, happily adding border-radius, which will soon be supported everywhere, while other aspects of CSS3 aren’t supported anywhere at all.

Be wary of browser “scoring” websites. They often test for things that have nothing to do with HTML5, such as CSS, SVG and even Web fonts. What matters is what you need to do, what’s supported by the browsers your client’s audience will be using and how much you can fake with JavaScript.

HTML5 Legalizes Tag Soup

HTML5 is a lot more forgiving in its syntax than XHTML: you can write tags in uppercase, lowercase or a mixture of the two. You don’t need to self-close tags such as img, so the following are both legal:

<img src="nice.jpg" />
<img src="nice.jpg">

You don’t need to wrap attributes in quotation marks, so the following are both legal:

<img src="nice.jpg">
<img src=nice.jpg>

You can use uppercase or lowercase (or mix them), so all of these are legal:

<IMG SRC=nice.jpg>
<img src=nice.jpg>
<iMg SrC=nice.jpg>

This isn’t any different from HTML4, but it probably comes as quite a shock if you’re used to XHTML. In reality, if you were serving your pages as a combination of text and HTML, rather than XML (and you probably were, because Internet Explorer 8 and below couldn’t render true XHTML), then it never mattered anyway: the browser never cared about trailing slashes, quoted attributes or case—only the validator did.

So, while the syntax appears to be looser, the actual parsing rules are much tighter. The difference is that there is no more tag soup6; the specification describes exactly what to do with invalid mark-up so that all conforming browsers produce the same DOM. If you’ve ever written JavaScript that has to walk the DOM, then you’re aware of the horrors that inconsistent DOMs can bring.

This error correction is no reason to churn out invalid code, though. The DOM that HTML5 creates for you might not be the DOM you want, so ensuring that your HTML5 validates is still essential. With all this new stuff, overlooking a small syntax error that stops your script from working or that makes your CSS unstylish is easy, which is why we have HTML5 validators7.

Far from legitimizing tag soup, HTML5 consigns it to history. Souper.

“I Need to Convert My XHTML Website to HTML5”

Is HTML5’s tolerance of looser syntax the death knell for XHTML? After all, the working group to develop XHTML 2 was disbanded, right?

True, the XHTML 2 group was disbanded at the end of 2009; it was working on an unimplemented spec that competed with HTML5, so having two groups was a waste of W3C resources. But XHTML 1 was a finished spec that is widely supported in all browsers and that will continue to work in browsers for as long as needed. Your XHTML websites are therefore safe.


Not at all. If you need to use XML rather than HTML, you can use XHTML58, which includes all the wonders of HTML5 but which must be in well-formed XHTML syntax (i.e. quoted attributes, trailing slashes to close some elements, lowercase elements and the like.)

Actually, you can’t use all the wonders of HTML5 in XHTML5: <noscript> won’t work. But you’re not still using that9, are you?

HTML5 Will Kill Flash and Plug-Ins

The <canvas> tag allows scripted images and animations that react to the keyboard and that therefore can compete with some simpler uses of Adobe Flash. HTML5 has native capability for playing video and audio.

Just as when CSS Web fonts weren’t widely supported and Flash was used in sIFR10 to fill the gaps, Flash also saves the day by making HTML5 video backwards-compatible. Because HTML5 is designed to be “fake-able” in older browsers, the mark-up between the video tags is ignored by browsers that understand HTML5 and is rendered by older browsers. Therefore, embedding fall-back video with Flash is possible using the old-school <object> or <embed> tags, as pioneered by Kroc Camen is his article “Video for Everybody!”11 (see the screenshot below).


But not all of Flash’s use cases are usurped by HTML5. There is no way to do digital rights management in HTML5; browsers such as Opera, Firefox and Chrome allow visitors to save video to their machines with a click of the context menu. If you need to prevent video from being saved, you’ll need to use plug-ins. Capturing input from a user’s microphone or camera is currently only possible with Flash (although a <device> element is being specified13 for “post-5″ HTML), so if you’re keen to write a Chatroulette killer, HTML5 isn’t for you.

HTML5 Is Bad for Accessibility

A lot of discussion is going on about the accessibility of HTML5. This is good and to be welcomed: with so many changes to the basic language of the Web, ensuring that the Web is accessible to people who cannot see or use a mouse is vital. Also vital is building in the solution, rather than bolting it on as an afterthought: after all, many (most?) authors don’t even add alternate text to images, so out-of-the-box accessibility is much more likely to succeed than relying on people to add it.

This is why it’s great that HTML5 adds native controls for things like sliders (<input type=range>, currently supported in Opera and Webkit browsers) and date pickers (<input type=date>, Opera only)—see Bruce’s HTML5 forms demo14)—because previously we had to fake these with JavaScript and images and then add keyboard support and WAI-ARIA roles and attributes15.

The <canvas> tag is a different story. It is an Apple invention that was reverse-engineered by other browser makers and then retrospectively specified as part of HTML5, so there is no built-in accessibility. If you’re just using it for eye-candy, that’s fine; think of it as an image, but without any possibility of alternate text (some additions to the spec have been suggested, but nothing is implemented yet). So, ensure that any information you deliver via <canvas> supplements more accessible information elsewhere.

Text in a <canvas> becomes simply pixels, just like text in images, and so is invisible to assistive technology and screen readers. Consider using the W3C graphics technology Scalable Vector Graphics16 (SVG) instead, especially for things such as dynamic graphs and animating text. SVG is supported in all the major browsers, including IE9 (but not IE8 or below, although the SVGweb17 library can fake SVG with Flash in older browsers).

The situation with <video> and <audio> is promising. Although not fully specified (and so not yet implemented in any browsers), a new <track> element18 has been included in the HTML5 spec that allows timed transcripts (or karaoke lyrics or captions for the deaf or subtitles for foreign-language media) to be associated with multimedia. It can be faked in JavaScript19. Alternatively (and better for search engines), you could include transcripts directly on the page below the video and use JavaScript to overlay captions20, synchronized with the video.

“An HTML5 Guru Will Hold My Hand as I Do It the First Time”

If only this were true. However, the charming Paul Irish and lovely Divya Manian will be as good as there for you, with their HTML5 Boilerplate21, which is a set of files you can use as templates for your projects. Boilerplate brings in the JavaScript you need to style the new elements in IE; pulls in jQuery from the Google Content Distribution Network (CDN), but with fall-back links to your server in case the CDN server is down.

HTML5 Boiler Plate22

It adds mark-up that is adaptable to iOS, Android and Opera Mobile; and adds a CSS skeleton with a comprehensive reset style sheet. There’s even an .htaccess file that serves your HTML5 video with the right MIME types. You won’t need all of it, and you’re encouraged to delete the stuff that’s unnecessary to your project to avoid bloat.

Further Resources

HTML5 is a massive topic. Here are a few hand-picked links. Disclosure: the authors have their fingers in some of these pies.

About the Authors

Remy and Bruce are two developers who have been playing with HTML5 since Christmas 2008: experimenting, participating in the mailing list and generally trying to help shape the language as well as learn it.


Bruce28 evangelizes Open Web Standards for Opera29. Remy30 is a developer, speaker, blogger and contributing author for jQuery Cookbook (O’Reilly). He runs his own Brighton-based development company called Left Logic, coding and writing about JavaScript, jQuery, HTML5, CSS, PHP, Perl and anything else he can get his hands on. Together, they are the authors of Introducing HTML531, the first full-length book on HTML5 (New Riders, July 2010).



  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31

↑ Back to top Tweet itShare on Facebook

Bruce Lawson evangelises open web technologies for Opera. He co-authored Introducing HTML5, the best-selling book on HTML5 that has just been published in its second edition. He blogs at

  1. 1

    Ok, then tell me, how to redirect IE 6 users with turned off javascript to a fallback page? If you do not use noscript, they will see a warning on a very messy page.

    Noscript is still needed, if it makes no sense to edit the dom.

  2. 102

    As a webmaster at first I really thought I would have to go out of my way to make changes to all my websites to prepare for this but truthfully none of this shit really matters, not to people that run websites at least.

    I’m not going to wake up one day and my websites stop working in the browsers, when changes are required, then those with the ability to make those changes will create simple solutions for all of us to use, the web always takes care of itself. HTML5 really isn’t a major change, and this is not a upgrade or die situation, if you don’t use it you’ll be fine.

  3. 203

    Since you started off with “Once upon a time…”, but you overlooked IBM Script. HTML began as a subset IBM Script tags and has been incorporating features of that markup language ever since. Nearly all original tags, such as li, p, br and so forth come directly from IBM Script.

  4. 304

    What about Flash portability, ive seen many demos the video of HTML5 isn’t really nice, i think nothing can replace Flash and SilverLight i was thinking why don’t they support they plugin and library by defualt on all browsers and OSs.
    What do you think also about webGL because you never mention, with webGL & SVG they can produce high-quality interactive content and games, that will definitely affect the flash market and usage, many website will think about produce plain html content for portability esp for mobile devices and handheld.

  5. 405

    I don't like extra work

    September 26, 2010 4:21 pm

    I don’t like to compromise on quality, but if I can more or less get the same result in less time, I am definitely going to go that route. Html 5 does have some neat things… but if I can replicate most of them with existing technology while spending less time… its going to be a hard sell to justify the added expense/time to myself or my clients.

    In all honestly it’s hard to understand all the hubbub about Html 5 when it just doesn’t make logical sense… unless you have money to burn on creating experiences using two separate technologies. I believe it comes down to the fact that writers and bloggers naturally get excited when there’s something new to write about. Same thing happened exactly when the web went from tables to CSS for layout. Lots of excitement, but of course tables would persist for years as CSS didn’t make sense with Micro$oft being on everyone’s computer. Of course the same company is still holding us back…

    End of story for me. But do wake me up years from now when Internet Explorer 6, 7 and 8 are finally all dead.

  6. 506

    Hey XML and XHTML are two different things!!!

  7. 607

    As amatuerish as introducing the marquee tag?

    He shoots, he scores!!!

  8. 708

    I think his point here is that XML has well defined error handling, while HTML5 (and related) has well defined error tolerance. In the syntax that is.

    But I agree with you, the adjective “well-defined” is not to be compared with XML, where the error handling is equally well defined.
    Bruce, it is to be compared to HTML4.

  9. 809

    Would you have found it ridiculous championing recording films in colour when the majority had black and white televisions too?

  10. 910

    IMHO opera and mozilla should have been slapped in the face and brought back on the XHTML2 wagon. Everything HTML5 brings us in features could have been added to XHTML2, leaving the “how to handle bad markup” incompatibilities between browsers behind us once and for all!

  11. 1011

    From author:

    A quick note to those who say “HTML 5 is still useless as Internet Explorer doesn’t support most of the features” and similar.

    A closer reading of the article (the section headed ““My Browser Supports HTML5, but Yours Doesn’t”) reveals the words “What matters is what you need to do, what’s supported by the browsers your client’s audience will be using and how much you can fake with JavaScript.”

    Here’s a useful site listing the JavaScript shims that plugs the holes in browser support:

    So, when using a new HTML5 feature, first use feature detection. If the browser supports a feature, do nothing: let the browser deal with it natively. If the feature is not supported, use one of the shims. Simple, easier and more elegant than the CSS hacks we’ve used for years to cater for older browsers.

    If you don’t approve of relying on JavaScript, that is your prerogative; no-one requires you to code HTML5 or use drag and drop, web sockets, etc. But note that HTML5 is made for web *applications* and it’s difficult to write an app that doesn’t use scripting.

  12. 1112

    The trouble is XHTML2 would break the web. It isn’t/wasn’t backwards compatible. Sir Tim made the right choice in bringing the WHATWG under the W3C umbrella–having the different browser publishers at the table and agreeing on the majority of point was a unique opportunity that would have been shameful for the W3C not to have been involved with. It doesn’t matter how good your standard is if no-one is going to implement or use it!

  13. 1213

    I have a good real world example for you coming up. :)
    Watch my blog.

  14. 1314
  15. 1415

    HTML5 Legalizes Tag Soup – So we cant use xml parsers to analyse websites.
    I think we need strict coding guidelines.

  16. 1516

    I don't like extra work

    September 29, 2010 4:22 pm

    Speaking for myself, I don’t at all think it’s useless. Nor do I have a problem with javascript, and switched from Flash to jquery a couple years ago for most animation. In fact I can’t wait to be able to use html 5. But what I don’t think that the “pro” html 5 side has really addressed is the question of whether the extra time one needs to make it work across all browsers cancels out some or all of the benefits. How it affects the cost of your bid, and/or your bottom end as a web designer? From what I gather, the workarounds are both time consuming and have a million hacks for this or that. What would be interesting to see would be an article focused on time/cost analysis… or even some type of a John Henry race. Then we could send it to our clients if it came out well ;)

    I have to disagree agree in most cases that much depends on what browsers your audience uses. From all the Google Analytics reports I’ve seen from all manner of clients, audiences use IE in more than good enough number to count. So unless maybe we are talking about an all Mac corporate intranet (!), or a Firefox user group site or something… you’re going to have to build two versions of your site unless you want to alienate a huge swath of customers.

    I’m sure some would call my attitude lazy. But in the beginning, wasn’t the whole promise of technology to enable us to have more leisure time in our lives? Ugg.. what ever happened to that. Instead we are supposed to embrace the idea that you can make your cart move better you cobble up your new shiny circular wheel to the old square one. But don’t forget the new javacript shocks that need to compensate for the bumpy ride…

  17. 1617

    A server side browser check on IE6 and redirect accordingly?

  18. 1718

    good share. thanks

  19. 1819

    how that is what i call an amazing article
    thank you guys

  20. 1920

    I’m with on this. This is very true about going around and around testing various rubbish that IE produces. Corporation should just kill IE6.

  21. 2021

    amen fellow james

  22. 2122

    Make the landing page (usually index.*) the actual fallback and if Javascript is enabled redirect to a much more enhanced page perhaps?

    Seriously there is many ways to do this without the “noscript” tag,
    all you need to do is put some thought into it.

    HTML5 is here and it’s usable for the most part, you may take advantage of it if you like, if not that would be your preference it really doesn’t concern us as we’re not the ones developing the sites.

    I understand the flaws within using HTML5 today but I also recognize the advantages, find out which one is higher than the other for you Then make your decision.

    Personally I like the idea that in 20 years if my site still exists it still works pretty well, without the need for what I imagine to be *by then* obsolete technologies such as Flash. As in 20 years I would imagine that HTML5 will be what HTML4 is now (still usable but with new things on the way).

    I use HTML5 in most my projects and I no longer care for IE6 (considering Microsoft killed it I should hope you don’t either).
    Also those people who have no choice as their job requires them to use IE6 well they shouldn’t be viewing my site while their working anyway so um yeah I don’t care.

    I say if you’re not all that comfortable using HTML5 in production at least play with it and it’s features.

  23. 2223

    I think hyping HTML5 as a Flash alternative is misguiding.

    HTML5 is a document format that has tecnologies for interactivity and styling connected that may or may not work based browser version or vendor.

    Flash is a cross platform application platform, and it’s compiled and hardware accelerated for performance.

    I’ve heard so many times “HTML 5 does video”. HTML 5 may display video in a box in your HTML if your using the right browser. But no way in hell you can layer 5 videos with alpha channels on top of each other, do interactive looping and dynamic sound mixing on these, and sleeping well at night knowing the stuff will work on more than 95% of the users computers.

    This is in no way the HTML5 creators’ fault, and it’s great HTML is evolving. If the HTML5 hype keeps Adobe on their toes forcing them further evolving the Flash Platform, all the better :)

  24. 2324

    All the videos and their alpha channels can be seen on – Norwegian stand-up comedian. Please let me know if you know of a similar HTML 5 showcase.

  25. 2425

    Plz anyone know about the good tutorial for html5 :)

  26. 2526

    Hey guys. I agree. Great article. I purchased the ebook yesterday but haven’t received it yet. It’s an ebook! are you going to send it to me?

  27. 2627

    Hello Remy and Bruce,

    Great thanks for your time.
    This will help us lot to grow in HTML5 area.
    we have started a html5 gallery also you can check HTML5 Arena

  28. 2728


    What about HTML5 vs etc.
    Will HTML5 in any way replace some of these technologies?


  29. 2829

    Thank you for the great facts…i have developed my site in HTML5, when i try to validate it with w3 validator it shows no error but a warning. I am still unable to understand that warning. Can anybody help me out to solve it? Any help appreciated…

  30. 2930

    We’re a group of volunteers and starting a new scheme in our community. Your site provided us with valuable info to work on. You’ve done an impressive job
    and our whole community will be grateful to you.

    My blog … Toby


↑ Back to top