Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

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.

Further Reading on SmashingMag: Link

First, Some Facts Link

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 20044 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 forms5, 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 Link

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

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 wiki6 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 JavaScript 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 library7. 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” Link

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 Link

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 soup8; 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 validators9.

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

“I Need to Convert My XHTML Website to HTML5” Link

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.

HTML5 Kills XML Link

Not at all. If you need to use XML rather than HTML, you can use XHTML510, 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 that11, are you?

HTML5 Will Kill Flash and Plug-Ins Link

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 sIFR12 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!”13 (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 specified for “post-5” HTML), so if you’re keen to write a Chatroulette killer, HTML5 isn’t for you.

HTML5 Is Bad for Accessibility Link

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 demo15)—because previously we had to fake these with JavaScript and images and then add keyboard support and WAI-ARIA roles and attributes16.

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 Graphics17 (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 SVGweb18 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> element 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 JavaScript. Alternatively (and better for search engines), you could include transcripts directly on the page below the video and use JavaScript to overlay captions19, synchronized with the video.

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

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 Boilerplate20, 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 Plate21

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 Link

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 Link

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.


Bruce25 evangelizes Open Web Standards for Opera26. Remy27 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 HTML5, the first full-length book on HTML5 (New Riders, July 2010).


Footnotes Link

  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

↑ Back to top Tweet itShare on Facebook

Bruce has been working on accessibility, web standards and browsers since 2001. That's why he looks that bad. You can follow him at @brucel, or read his ramblings at

  1. 1

    Fantastic Post! I’ve been waiting for this since Bruce tweeted about writing it!

    HTML5 is great, I’ve been using it on all my sites since Bruce’s talk at Future of Web Design and I really like. It’s really not that much of a learning curve and you end up with a really clean, semantic website at the end of it and the feeling that you’ve done something good for the web!

    HTML5 is very much like CSS3 in that if you’re not using it now, then you’re an idiot! There is no reason not to be using it!

  2. 2

    my view!

    no matter when the browsers will render, use HTML5

  3. 3

    It is funny how people get excited about technology sometimes. I am sure that there will be workaround posts, hacks posts and such about how to get something working on IE7 for example.

    I would really appreciate if Microsoft buy everyone around and we develop for and use only one browser, whatever it may be (preferably web-kit based…for now).

  4. 4

    I pretty much agree with you Luca, it can be much better to keep things simple and avoid unnecessary complexity at this moment. But I think we (designers and developers) will be someway pushed in that direction for the next months on, as clients will demand that their websites to look and feel like other ones and to work in many diferent devices.

  5. 5

    Can someone complete the following conversation for me?

    Me: “Here is our budget for your website. You’ll see we are using HTML5, which is totally awesome! But because some common browsers don’t support all of its features, we are also duplicating some parts in Flash and JavaScript.”

    Client: “So I’m paying you to build the same stuff in HTML5 and also in Flash and JavaScript.”

    Me: “Yes.”

    Client: “And these new browsers that run HTML5, don’t they run Flash and JavaScript too?”

    Me: “Yes, unless you are looking at this on an iPad.”

    Client: “Well iPad users are only 1% of our traffic. Let’s cut HTML5 development down by just using Flash and JavaScript because you were building that anyway.”

    Me: “Well that’s a bad idea because HTML5 …”

  6. 6

    As far as IE6 compatibility, I have a feeling we will be battling that for at least 3 more years, especially with some devices still using it as a browser.

    HTML5 is an interesting idea, and definitely opens up some doors, but truthfully, it might open up too many doors. Just wait till a malware/virus attack goes out and utilizes html5 as it’s core. It’s coming and will be probably much worse than any previous attacks due to the capabilities opened through html5.

    As far as flash, I’ve seen some beautifully implemented interfaces, and a lot more horrible interfaces. Flash is a plug in made for the desktop in a more mobilly(new word!) growing world. I feel that as more devices support flash lite, and the ‘bandwagon developers’ (similar to html5 developers who want to code sloppy) finally realize their cheery flash animations aren’t generating any business, the flash world will gain more respect.

    But as far as HTML5 goes, its a fad, with a cool ‘newish’ name, for older technologies only supported by few browsers. As developers we have to look at our audience, and their browser capabilities. I’m sure my audience only contains about 5% of viewers who could actually utilize HTML5 features to their true usable requirements.

    Want to do good to your users? Develop sites that are well structured, compatible, and utilize frameworks that enable better experiences on current technologies, and when other technologies arrive, feel free to play with them, but don’t expect someone else to fund a project or technology that isn’t even widely available to audiences yet.

  7. 7

    The day that Google starts indexing based on HTML5 markup structure (do they already?), it will be pretty much critical to make the move given the additional semantic properties.

    The question is, how do you support non-HTML5 browsers, while using HTML5 markup, without the aid of a Javascript fix?

  8. 8

    I would be more careful and really figure out who your target audience before utilizing HTML5. I’m not sure if you have ever been exposed to corporations, but a lot of our clients use IE6 because that’s part of their system and they have a lot of custom apps programmed for that platform. For them, it’s not as easy downloading the latest service pack for windows…We are talking million dollar upgrades…

    Also, a lot of people are completely oblivious to what’s happening on the web, your part of a small bleeding edge group – don’t assume everyone is like you. When you dig for user stats, make sure your data in not biased. For example w3school is the last place to get real data as their audience is us.

  9. 9

    Clients don’t usually care about that.

  10. 10

    The spec for HTML5 has of great interest to me for a few months now. It’s support in Chrome (and Safari?) has been pretty good, but the wait for it to become a set standard/supported in the majority of browsers is going to be long and hard for me! I love using the more descriptive tags, the structure of a page definitely makes more sense, and can’t wait to build websites using HTML5.

  11. 11

    Man, exactly. That’s why I simply can’t bring myself to embrace it yet. It’s one thing to rely on Javascript to render a dropdown correctly, but entirely something else to rely on it for the layout of the entire website!

  12. 12

    just learning web design/coding now. wow, so many different “languages” HTML, XHTML, CSS, HTML5, XML, Javascript, JQuery……

  13. 13

    If you were around many years ago when Flash was first introduced, you’ll remember that at that time it took AGES before we started seeing creative, multimedia-rich websites that used all of the advantages it offered. In the beginning it was really just a case of online animation experiments here and there and then things improved rapidly as time went by.

    With HTML5, it’s going to be a similar case. Right now you’ll find hundreds of little experiments using the Canvas element (and HTML5’s other elements) to achieve something visually impressive, but in terms of real-world applications of HTML5, I don’t think you’re going to see a large quantity of sites (and developers) switching over to using it completely for some time yet.

    The reason in my eyes is this: We’ve only JUST gotten rid of the compatibility coding nightmares caused Internet Explorer 6 (and barely at that, as has been mentioned some people do still use it). Developers are tired of coding multiple experiences just to satisfy backwards compatibility of those browsers that don’t support HTML5 well yet and until IE9 begins to see greater usage numbers, I for one really don’t want to be in the ‘Create this in HTML5, replicate this in Flash’ boat, even though I LOVE using HTML5.

    If we can get to a point where we’re only needing to create one experience for the desktop and perhaps another that’s mobile optimized (of course there will still remain some per-browser issues, but not as many) I think that I’d be more happy to begin using HTML5 in any or all of my projects.

    My two cents :)

  14. 14

    Thanks for your response there ‘Age’, I have in fact been exposed to corporations as the majority of our clients are corporates who are, as you very accurately point out, using IE6. But this has not stopped us from implementing HTML5 in anyway and I am not sure why it would?

    If you take the time to read the above post, you can see it states that any functionally that is not available in a browser can be easily faked with Javascript, which is what we do.

  15. 15

    If you want to learn a great server-side language, I’d recomment ColdFusion. Like HTML/XHTML, it’s tag-based syntax, for example, and if loop:

    [cfif i eq 5]do this[/cfif] (Most all tags in ColdFusion begin with cf) Also, I cannot use open/close tags in this editor because it tries to interpret it, so the above code is using the same characters.

  16. 16

    ..especially if your clients are outside U.S.

  17. 17

    HTML 5 is still useless as Internet Explorer doesn’t support most of the features.

  18. 18

    Funny how similar the “First The Facts” of this article are to a blog I wrote about HTML5 Awhile ago.

  19. 19

    I agree. Allowing “Tag Soup” is a step backward IMO. Some developers code is hard enough to go through as it is…allowing them to do whatever they want in terms of structure and standards is going to encourage sloppy coding.

  20. 20

    It is a pitty we basically have to do things twice for graceful degradation…but I’m sure we’re all pretty used to this because of M$.

    On a different topic…why don’t they just let IE die? It doesn’t make them any money and it certainly isn’t a selling point (like IE6 was in it’s day). Is it just for simple presence?? And if that is the case, why do they “try” to be trail blazers….just conform and work with the rest of the world to make things better.

  21. 21

    Till some years ago, every time I programmed a site, I had to test a lot for ie6, ie7, safari and ff. Then, finally, ie6 is quite DEAD, and I reduced my test time A LOT.
    Should I go back and test a lot for the various browsers just to be HTML5-that-trendy? NOT AT ALL. ie7 and ie8 do not support it natively, you have to wark around all that in various ways, and check that your site fall back gracefully. Well. NO. ie9 is fine with html5, but you will still have to check ie8. Again, NO. I do not want to restart all that testing. NO. I’ll probably wait ie 10… And once again.. Microsoft is taking all us away from the real future..

  22. 22

    /me waves! .. nice article to share bruce!

  23. 23

    Jeremiah selengia

    September 23, 2010 5:52 am

    Great post. Interesting to see how accepted this will be

  24. 24

    Well that clears that up! Nice one Bruce and Remy.
    P.S. Anyone scared to dip into the HTML5 waters having bathed in XHTML for a few years, if you have reached a zen of clean minimal mark-up you will love HTML5 for it’s fresh semantic vocabulary. Utlisise ARIA roles for extra purpose and semantics and to specify your styles and you’ll never look back. ‘Fakin it’ for IE could not be easier either.

  25. 25

    Nice article on HTML5 truths and myths.

    Just couldn’t understand why whatwg link didn’t figure out on further resources section.

  26. 26

    I actually liked holding my code to the strict syntax of XHTML. Nothing’s better than a page that fully validates and the source code looks prim and proper.

    ( Removed this section because editor won’t show my code examples literally – it tries to interpret it )

    …something OCD-ish makes me love the look of the former and not the latter.

  27. 27

    I cant tell if you are pro HTML5 or not from your comment. Both XHTML and HTML5 allow for you to maintain a strict syntax (a la XHTML) and they will both validate.

  28. 28

    No man! Please not Microsoft!

  29. 29

    IE6 is still over 6% in global usage, and depending on your sites visitors, considerably higher than that. The reality is, until we get rid of this technological debacle, we’re going no where.

  30. 30

    The number of users who browse without JavaScript is minimal

    Screen Readers CAN read out text inserted via JavaScript as well.

  31. 31

    …. is so totally cool and awesome, and cool… and stuff… Did I mention it was cool! You dont even have to code your DOM correctly! So what if the code does not operate in previous browsers? Whose using those anyways! Why should I not jump on the HTML5 bandwagon and parade around? I mean common! We are the greatest web developers in the world!

  32. 32

    Thanks for all this clearing information!

  33. 33

    What about “HTML 5 Kills a state-of-the-art processor doing a simple parallax movement”? or animations aren’t smooth at all?

    Nice article! Love Smashingmagazine

  34. 34

    Why do HTML5 sites only talk about Flash as if it only does video? There are hundreds of other major capabilities that Flash already allows that HTML5 doesn’t.

    I’m excited about HTML5 just like everyone else but my biggest beef is that new innovations can take a decade to get through to major market penetration where as with Flash, within a year of a new plug-in release, upwards of 90% of users support it. I’m just not convinced that “open source” is the best solution for something like this.

  35. 35

    I’m all for HTML5. With what I’ve seen, I’m very eager to learn it inside and out. My thing is, I’m partly OCD, and when I view someone’s code, allowing them to alternate 1 tag’s attribute casing and whether it has quotes around it or not just reeks of unprofessionalism.

    I never subscribed to the belief “Well, if it looks/works right in the browser, it’s fine however it was coded”; I take pride in my code being as clean, well documented, and easy to follow as possible (something HTML5 will allow, of course)

    My biggest beef is that IE continues to make vendor-specific CSS attributes even with version 9. It’s like they know what’s best for the web and they actively work against that goal. We need standardization and not competition.

    I tell people, “If something at work made you have to work X% harder for 0% more pay, you’d be against it, right? Well that’s what MSIE is for web developers; something that requires us to fanagle and manhandle our code just to get it to work properly.”

    I understand end users shouldn’t be bothered with this reality, but Microsoft seems to be the worst thing that could happen in the web’s development history.

  36. 36

    Most clients don’t know: “browser”, “IE”, “JavaScript”, “HTML5” either. They just want the end product, and without clarification, leave all the nuances up to you to ensure that it runs everywhere properly.

  37. 37

    Nice article, but why not just skip htlm5 and go straight to xhtml5?
    It seems like it would allow for even more uses and since it’s xhtml it’ll make your code look cleaner?

  38. 38

    The problem really lies with what audience you are working with. If you want a cool artistic site aimed at other designs, then yeah go nuts with the HTML5. But if you’re working for a client, you should grab any analytics they have on their audience and assess what kind of site and technology you are going to use.

    If that information doesn’t exist, and you are trying to get people to the site, then you need to use what is most accessible. Not to mention I think most designers can do whatever they want with flash+xhtml+css. Sure something may be much easier using css3, but I’m so used to how to make it with css2 that I’m not saving that much time, and my css2 version is accessible to a wider audience (generally speaking).

    So while I’m not going to harp completely on HTML5, I’m just not really going to use it right now. I’ll seek out css3 and html5 stuff and see if it has a place in my xhtml/css2 designs, and just pick up the tags that why. Mostly though I’m fine without it.

    Then again maybe I’m just stubborn and I should get with the times before I stubborn myself out of a job in 5 years! Kidding, because the unspoken side of the design industry is how many senior level designs know very little of modern / current technology. You can walk into too many internet-based marketing companies with tons of knowledge that you think is pretty general and typical stuff, and find out that no one there knows what you’re talking about and they’re fine hacking together their non-compliant sites in Dreamweaver.

  39. 39

    I’m done with IE6; I simply don’t develop for it.

    Every client I’ve spoken with, I’ve explained in simple terms the history of browsers and why IE browsers are popular (not by choice) I let them know “Your browser will look and work fine in IE7+, Firefox and other modern browsers, but it will not in IE6”

    So far, no client has refused (many appreciated the lesson).

    Simply put, IE6 just isn’t a browser. It’s such a poor conglomeration of pitiful interpreters and piss-poor proprietary tech that the best thing I as a web developer can do to Microsoft is say “Enough is ENOUGH”.

  40. 40

    Anyway, XHTML site can be adapted in (X)HTML5… so XHTML is not going to disappear. :)

    By the way, very interesting article.

  41. 41

    Great article! thanks :)

  42. 42

    Don’t forget Jeremy Keith’s “HTML5 For Web Designers”:

  43. 43

    The way I see it is a big part of HTML5 is just an open web standards technology to compete with Flash. Having Flash out there with such a dominant market share using a propriety technology is just not good for the web long term. Whether we like it our not this needs to happen to move the web forward to what was actually envisioned when Tim Berners Lee designed it.

    The problem I see here is not only is there a number of levels of bureaucracy that hinder the development of HTML5, it’s the fact that Adobe has had 10+ years to develop Flash. Imagine how long it’s going to take for HTML5 to really compete with Flash in things other than displaying a simple video with content protection. Flash makes millions of dollars on this technology alone.

    It’s just going to be a big mess. We designers are delusional if we ever think the web is going to be truly 100% open with web standards. As long as there is millions of dollars at stake this will never happen.

  44. 44

    Bertil Wennergren

    September 23, 2010 11:41 am

    It’s really interesting how many web developers ignore that using HTML5 now means tying the pages to JavaScript: With JavaScript deactivated the pages will fall apart completely (for a considerable number of users). That’s OK if you’re doing a web app that will be dependent on JavaScript anyway, but it’s madness otherwise.

    And what about Lynx What about screen readers? Will your pages work for those categories? Does anyone care anymore?

  45. 45

    Very thorough article.

  46. 46

    In my experience, a client is more likely to say, “why doesn’t this work on [insert hip new technology]?!?” Rather than, “let’s save money and not support [insert hip new technology].”

    That said, your browser matrix tells you which technologies to choose from. HTML5 features are just more tricks in your bag, allowing you to provide more broad support, if it makes sense.

    A few years ago, the client would just be out of luck.

  47. 47

    Okay, let me rephrase the question then. I’ve got a limited budget – be it time or money. If I’m going to build a site, what is the advantage of building features in HTML5 that will need to be duplicated in Flash or JavaScript for the time being? Eventually 95% of browsers will support 95% of HTML5 and we won’t have to duplicate features, but until then I have a hard time justifying the additional time/money to duplicate features. I just want to know if there is some reason for doing it this way that I am not considering or aware of.

  48. 48

    Yes, it’s a GREAT book goes into a lot of detail about all this stuff.

  49. 49

    You can still use xhtml coding syntax so that your code looks cleaner…I think the point is that people that don’t know how to code well (clean) won’t break the sites that they’re working on.

  50. 50

    Just a quick note:
    Under About the Authors, link to Introduction to HTML5 has a typo.. :)

    Good job otherwise.

  51. 51

    Brilliant article that clears up some of the hype and myths surrounding HTML5.

    BTW, the book by the authors is an excellent primer for HTML5.


  52. 52

    Maybe you should read the post again!

  53. 53

    My thought exactly. I’ve studied HTML5 for a while, really love all the features and would like to start using them today. But the idea of supporting older browsers by javascript only holds me from using it. Also the client budget ( thanks Nacnud for the illustrative way of making this point ) is an issue for me.

  54. 54

    Since i here about HTML5 i am skeptical. That’s cause of two reasons.

    I am not that long in the design and markup sector commercialy, but doing sites for nearly 10 years. My clients want a site that runs on EVERY Browser (OK not on ie5 and all the exotics i hope), and thats also my claim of doing a good work. And if they not fully looks the same, then at least everybody should have the possibility to consume the content.
    I mean, sure everybody of the HTML5-followers says: “no probleme, it can all done by fake functionality with javascript”. Sure it can – but at which costs? Bring examples and real life examples. Nobody wants HTML5 when you have to done (lets say) twice the work to do backward compatibility for ie6-ie8 and some other browsers that don’t understand some of the elements.

    I love to develop in xhtml cause it always has to be well-formed. OK, you can write HTML5 as XML, and i will do that – cause its save. But i scared of people how don’t do that. Soon or later you have to take your hand on sites anyone other has developed to correct or extend something. And i bet if its HTML5 in 70% your confronted with all that nasty stuff that is allowed but awkward. Big element names, no closing elements and some really bad coded javascript.
    I think THERE SHOULD BE A STYLE GUIDE FOR HTML5-CODE. For JAVA there is an official one, and all good companies in web-development have one for PHP or Ruby. Why not also a official or at least generally accepted for HTML5?

  55. 55

    All markup should be available without javascript or at least at some way accessible. If it isn’t for the 1% ( or maybe less? :P ) users, let it be for the searchengines. The describes solution in isn’t hard to implement and simply a better way. Try it and find out yourself that using <noscript> is a bad idea ;)

  56. 56

    ah… one appendix:
    I love to read about some major-sites using HTML5. I am sure there some how uses one or two elements. I think, when the big sites start to using HTML5 then its time to adapt it.

  57. 57

    I noticed nothing was mentioned about validation, W3C’s validator currently has HTML5 as a “experimental” ( not unicorn). With the browsers formatting the DOM the same is validation no longer important?

  58. 58

    You can ignore it for as long as you like, or you can use it where it simplifies your code (and use an external JavaScript library to ‘add’ backward compatibility at cost of site speed to earlier IE versions).

    The other thing is simply taking your 4.01 site and validating it against 5 – remember that a lot of the 5 spec is about defining HOW browsers should handle mark-up errors / contradictions, and moving further styling tags from HTML to CSS.

    Just like the move to 4.01, it can be seen as a way to further ‘clean’ your code, while still being backward compatible.

  59. 59

    Some of the comments here worry me. It’s like some of you are scaremongering and in turn holding back others. I don’t think many of you have really read this article let alone what html5 is all about. You can feature detect too and have a fallback for IE6 et al. (if you even care about them), if is important and you want to implement the geolocation JavaScript API, for example, then obviously you client/customer can’t have it all.

    There’s no reason at all to not use the HTML5 doctype for a start – and

  60. 60

    Have started using HTML5 Boilerplate and its makes a lot of sense other than denying it, you will end up learning a lot of stuff…

  61. 61

    Sorry, I can’t let your comment go unchallenged Jim.

    Nowhere do I imply that XML chokes on unrecognised element types, attributes and attribute values, as those are not errors.

    But an error of well-formedness, such as a single unencoded ampersand, missed trailing slash is erroneous and therefore the draconian error handling takes over.

    Am I incorrect?

  62. 62

    Nice article :)
    Can we expect a same sort of article on CSS3 because that would also be great!
    keep up the good work, I really enjoy reading the articles here on Smashing Magazine :D

  63. 63

    What are you talking about ? All the semantic tags can be styled with ie. If they don’t have a special behavior, no problem. No need for JavaScript, at all !

  64. 64

    You : well it’s a bad idea because there’s one special user called GoogleBot who doesn’t like flash and not so much JavaScript too, and he’s the reason why almost all of the other visitors are coming to your website.

  65. 65

    How is it moving the web forward by taking it back five years to what Flash could do in Flash Player 6? I agree that it’s bad for Flash to be the *dominant* technology but I hope that plugins like Flash and Silverlight remain popular because that’s where the real innovation that moves the web forward happens. Don’t get me wrong, I like HTML5 too and believe that it should always be used in preference to Flash where it makes sense. I think (and hope) they can all co-exist.

  66. 66

    OK now that looks like a lot of fun dude.

  67. 67

    Yes, but for unrecognized tags in IE that contain child elements, these child elements will instead be interpreted by the DOM as siblings. For this reason, a js workaround is essential in IE.

  68. 68

    Yes, I still use noscript. If nothing else it is the simplest way to remind people to turn on javascript.

  69. 69

    I agree the older versions of IE are a problem, but short of coming out with new versions, Microsoft can’t do much. They’ve put IE in Windows Update, you can’t run IE6 on new versions of Windows, and even many of Microsoft’s newer sites don’t work in IE6 or IE7.

    Do you expect Microsoft to hire a paramilitary force to go around making people upgrade?

  70. 70

    I think you meant to say Internet Explorer is useless as it doesn’t support most features of HTML5

  71. 71

    Nice article :)

    And I expect posts of open source HTML5 apps and tutorials…..
    believing others may also expect…

  72. 72

    I have very recently stopped catering for IE6 by default and I am certainly in no hurry to switch to HTML5 and start doing it all over again for IE7 and 8.

    I need a well deserved break from backward compatibility IE coding :)

  73. 73

    Arthur Abogadil

    September 23, 2010 9:19 pm

    A good writeup of some of the relevant issues surrounding html5, i’m still using xhtml on my projects, but is really considering jumping to the html5 bandwagon very soon.

  74. 74

    good article – super useful

  75. 75

    The number of people in wheelchairs is also minimal. The number of people using Opera is minimal. The number of people worth over a billion dollars are minimal. To heck with them?

    A poor argument.

    Javascript as an enhancement is fine. Javascript to fix markup and make it work?? Not for me, maybe fine for others.

    Screen readers can only read text added by Javascript if the user has Javascript enabled (like anyone else). And older readers suck at it (many user virtual buffers, which only in more recent versions actually detected a change in the DOM and updated the buffer).

  76. 76

    Just saying to exercise some caution before you call everyone an idiot for not using HTML5/CSS3. There’s a lot of politics that go on behind the scene. Interesting tweets btw…

  77. 77

    I like the paramilitary option :)

  78. 78

    Nice article,

    I do not agree on the premise of making MS the base of all evil. Especially bashing MS for the fact that users are still using IE6…. please…. not MSs fault.

    I do hate the fact that it is caseinsensitive and not scrict in syntax, but I guess that comes from being a C# developer :-) (I still consider this is legalizing tag soup)

  79. 79

    Hi Volly,
    One : Download boilerplate (as mentioned in the blog). It includes all the iefixes as part of the package and you have no further work to do. Instead of modernizer you can use selectivizr just to utilise advanced css selectors.
    Two: You can still code to XHTML rules – HTML5 just accepts what browsers accepts – which includes your ‘well-formed’ syntax.
    The transition is really simple and you basically have a wider more semantic set of elements to work with. Get stuck in!

  80. 80

    Very good!

    Thanks for the “HTML5 Is Bad for Accessibility” clarification.

  81. 81

    > Well-defined error handling, like CSS (i.e. ignore unknown stuff and move on), compared to XML’s “draconian” error handling.

    You’re propagating a myth here yourself. XML’s “draconian” error handling only covers malformed syntax, not validity. You can use as many unrecognised element types, attributes and attribute values as you like and an XML parser can quite happily ignore them, same as with CSS. It’s simply not true that any deviation from spec results in a fatal error, yet a huge amount of FUD gets thrown around saying otherwise, and the way you put it only serves to reinforce this myth.

  82. 82

    Having requested their upgrade plans over the past few years, we’ve recently had two clients turn round and ask if the site works with IE8′ – the fact that IE6 will soon be out of any support has started to concentrate their minds – it is the kind of thing external auditors pick up on.

    And of course with IE9 tied to Windows 7, it’s unlikely we’ll ever be able to use ‘full HTML 5’ on the desktop before the 2020s.

    On the other hand, where clients are requesting mobile device sites, you may as well go HTML 5.

    It’s also notable that our most technically laggard clients don’t tend to actually commission much in the way of new work, anyway.

  83. 83

    Banner Designer

    September 24, 2010 4:20 am

    No Words for html5…Such A cool Advancements are there…My coding got reliable now…Just waiting for the time when every body uses updated versions of browsers…

  84. 84

    Christopher Anderton

    September 24, 2010 4:48 am

    For clients. I always say if they cut the IE6 support, they will get a better price.

  85. 85

    Nice aricle. Thanks for sharing this.

  86. 86

    totally agree takes away the “standard” out of the equation, the beauty of xhtml is that it forces the coder to write proper syntax like a proper programming language, for us engineers is the way to be

  87. 87

    Thanks, we now know we’re all idiots : )

  88. 88

    Of course, the irony is that mobile browsers are getting there ahead of their desktop brethren.

    Hence the rise of Sencha Touch etc

  89. 89

    nice article….
    Please check HTML5 showcase..

  90. 90

    > Nowhere do I imply that XML chokes on unrecognised element types, attributes and attribute values,

    You compare CSS’s error handling as able to ignore unknown stuff and move on, in contrast to XML’s draconian error handling. It might not have been your intention, but it does indeed imply that XML’s error handling causes browsers to choke if they see something unknown.

    > as those are not errors.

    Yes they are. If, for example, you use the font element type in an XHTML 1.0 Strict document, that is an error as that document type doesn’t include any such element type. But XML parsers will happily ignore it.

    > But an error of well-formedness, such as a single unencoded ampersand, missed trailing slash is erroneous and therefore the draconian error handling takes over.

    Yes, that’s correct. It essentially boils down to a matter of syntax versus semantics. If the syntax is compromised, all bets are off with regard to being able to recover useful data; it’s an unknowable quantity. If the semantics are compromised, then that’s not a matter for the parser to make decisions on, so up the stack it goes.

  91. 91

    HTML5 and CSS3 .. another way to print books and make money .. When IE supports this technologies it will be time to learn them .. I do not think it will take much time to learn them .. when needed!

  92. 92

    IE6? The browser I’m forced to use at work because of corporate edicts?
    BTW, this web site looks pretty bad on IE6. I had to go to Firefox, which I’m not supposed to have installed on this system…

  93. 93

    I find it ridiculous how anyone can champion the cause of HTML5, even though it has far from universal saturation. Also, relying on a uncertainty (javascript) to render a web correctly is very amatuerish…

  94. 94

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

    Of course, there’s no way to do it effectively in Flash either. Just because there isn’t a “save” option on the menu doesn’t mean it isn’t possible and even quite easy to do it anyhow. There are good reasons to use flash for some content, but this isn’t one of them.

  95. 95

    @Volly HTML5 is the future embrace it.

    The issues you describe are just as evident regardless of the markup specification you use. All work needs to be checked in different BVP combos.

    I agree with what Addy Osmani states above emerging technologies are better able to offer this.

    Browsers are like diner guests some have more style and sophistication than others; with boilerplate you can provide one serving to all without issue.

    Kroc Camen as mentioned here is a great source of information, HTML5 Gallery and The doctor.

    the web benefits from the efforts of those that have taken the time to pitch hmtl 5 and I am grateful for it

  96. 96

    @Norman You need not get books to learn html5 & CSS3 – I assume you have web access – google is you friend search and you shall find

    @IE6_Till_I_die universal saturation just does not exist on the web there are far too many differentials; some browsers are amature in terms of the functionality they support – using JS to bridge this gap is a valid option; good js is good practice

    @/b thats another thing altogether; plugins don’t make this foolproof

  97. 97

    I totally agree, HTML5 Will Kill Flash and Plug-Ins is not true at all.
    HTML 5 just enables easier fallback in case flash and other plugins are not supported.
    I see all of them as tools to use to your advantage, and use them all.

  98. 98

    There is one very big reason why some browsers are different from Internet Explorer. If you use AOL, 32bit Web Browser, Avant browser, FlashPeak, GreenBrowser, Maxthon, Sleipnir, Smart Bro, Visual Explorer, WebWindow etc they all use the same code engine and work the same way.
    If you use Netscape (now SeaMonkey), or any of the other browsers that have grown from Netscape (Safari, Google Chrome, K-Meleon, Firefox, Opera from version 8.5 etc) they are not only different from IE but not compatible with other versions of Netstape.
    They need to agree on a set of rules (even if it’s not the W3C rules and get all their versions compatible with other versions of Netstape.)
    You may spend more time getting a page to work with IE than any other browser. But once it works with IE it will works with all IE clones.
    Get your page to work with Chrome and it still may not work with Firefox and some other browsers that have grown away from Netscape.

  99. 99

    Dudes, standards are not about how clean the html looks in your text editor but how predictably it gets rendered in the browser.

    HTML5 effort to standardize error handling is much more valuable than XHTML effort to mandate a strict syntax without saying anything about error handling.

    If you supported XHTML strict syntax dreaming that one day the browser would’ve parsed it like XML, stopping and throwing yellow screens of death with malformed markup, well that was just a pipe dream.

    The web is a messy thing and you just can’t expect that people would allow entire webpages to fail because of a tiny bug in the last CMS update, or because of a suboptimal sanitizing filter for comments, of because of a legacy ad system with quirky markup.

    So, without being enforced by the rendering policies, XHTML “proper syntax” was just a nuance for conscientious authors… just exactly like it will be in HTML5.

    If you feel so, keep authoring with strict syntax rules, I for sure will bless you if I happen to end up editing a document of yours – but don’t whine about HTML5 being a step backward because it didn’t spoil you of anything.

  100. 100

    Actually, neither Google Chrome, Safari or Opera ‘grew’ from Netscape. Google Chrome and Safari use WebKit to render HTML, and Opera uses its own Presto engine.

    Firefox and K-Meleon both use the same Gecko rendering engine, so should be compatible, excepting new features included in Gecko which K-Meleon hasn’t yet adopted.

    Chrome and Safari are compatible in the same way.

    The only reason IE’s use is so widespread is because it is the default browser in Windows. I doubt many of the (mostly corporate) IE users today actually browse with the ‘alternatives’ based on it.

  101. 101

    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.

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

  103. 103

    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.

  104. 104

    mohammed shehata

    September 26, 2010 1:34 pm

    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.

  105. 105

    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.

  106. 106

    Hey XML and XHTML are two different things!!!

  107. 107

    As amatuerish as introducing the marquee tag?

    He shoots, he scores!!!

  108. 108

    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.

  109. 109

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

  110. 110

    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!

  111. 111

    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.

  112. 112

    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!

  113. 113

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

  114. 114
  115. 115

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

  116. 116

    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…

  117. 117

    A server side browser check on IE6 and redirect accordingly?

  118. 118

    good share. thanks

  119. 119

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

  120. 120

    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.

  121. 121

    amen fellow james

  122. 122

    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.

  123. 123

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

  124. 124

    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.

  125. 125

    Plz anyone know about the good tutorial for html5 :)

  126. 126

    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?

  127. 127

    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

  128. 128


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


  129. 129

    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…


↑ Back to top