Menu Search
Jump to the content X X
Smashing Conf San Francisco

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. upcoming SmashingConf San Francisco, dedicated to smart front-end techniques and design patterns.

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 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 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 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 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 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 library4. 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 soup5; 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 validators6.

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 XHTML57, 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 that8, 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 sIFR9 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!”10 (see the screenshot below).

Screenshot11

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

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 Graphics14 (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 SVGweb15 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 captions16, 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 Boilerplate17, 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 Plate18

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.

Screenshot

Bruce22 evangelizes Open Web Standards for Opera23. Remy24 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).

(al)

Footnotes Link

  1. 1 http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html
  2. 2 http://www.hixie.ch/specs/html/forms/web-forms
  3. 3 http://wiki.whatwg.org/wiki/FAQ#When_will_we_be_able_to_start_using_these_new_features.3F
  4. 4 http://excanvas.sourceforge.net/
  5. 5 http://en.wikipedia.org/wiki/Tag_soup
  6. 6 http://html5.validator.nu/
  7. 7 http://mathiasbynens.be/notes/xhtml5
  8. 8 http://www.wait-till-i.com/2005/06/21/six-javascript-features-we-do-not-need-any-longer/
  9. 9 http://www.mikeindustries.com/blog/sifr
  10. 10 http://camendesign.com/code/video_for_everybody
  11. 11 http://camendesign.com/code/video_for_everybody
  12. 12 http://people.opera.com/brucel/demo/html5-forms-demo.html
  13. 13 http://dev.opera.com/articles/view/introduction-to-wai-aria/
  14. 14 http://en.wikipedia.org/wiki/Scalable_Vector_Graphics
  15. 15 http://code.google.com/p/svgweb/
  16. 16 http://people.opera.com/brucel/demo/video/multilingual-synergy.html
  17. 17 http://html5boilerplate.com/
  18. 18 http://html5boilerplate.com/
  19. 19 http://dev.w3.org/html5/spec-author-view/
  20. 20 http://www.html5doctor.com
  21. 21 http://code.google.com/p/html5-shims/wiki/LinksandResources
  22. 22 http://twitter.com/brucel
  23. 23 http://www.opera.com/developer
  24. 24 http://twitter.com/rem

↑ Back to top Tweet itShare on Facebook

Advertisement

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 brucelawson.co.uk.

  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!

    -9
  2. 2

    my view!

    no matter when the browsers will render, use HTML5

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

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

    -2
  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 …”

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

    3
  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?

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

    5
  9. 9

    Clients don’t usually care about that.

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

    -1
  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!

    -1
  12. 12

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

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

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

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

    -2
  16. 16

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

    -2
  17. 17

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

    2
  18. 18

    Funny how similar the “First The Facts” of this article are to a blog I wrote about HTML5 Awhile ago. churchandwebdesign.com/2010/simplicity-of-html5/

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

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

    3

↑ Back to top