Recently I’ve been reading a lot of articles on HTML5 (such as on Zeldman.com and HTML5 Doctor), and have seen a few reoccurring false perceptions in the comments. While some may seem funny for those following HTML5’s progress closely, a lot of people aren’t, nor can they be expected to.
Browsers don’t support HTML5 #
Ref: When will we be able to start using these new features?—WhatWG FAQ
IE doesn’t support HTML5 #
Ref: What about Microsoft and Internet Explorer?—WhatWG FAQ
HTML5 won’t be ready until 2022!? #
While this statement makes for good WTF-style headlines, it’s just not true. The 2022 date is for two complete implementations, something that has still not happened for HTML4, XHTML 1.0 or XHTML 1.1. The dates to worry about are 2012 for a completed draft, and October 2009 for a working draft. That’s three months away yo! Also as stated above, browser makers are already implementing some of the new parts of HTML5, and the rest is backwards compatible.
Ref: When will HTML5 be finished? and When will we be able to start using these new features?—WhatWG FAQ, and for fun Is HTML5 Ready Yet? and Is HTML5 Ready? ;-)
You mean XHTML isn’t the future!? #
No, it’s the present. XHTML2 may be dead, but nothing will stop the millions of current XHTML 1.x pages (and any you create in the future) from working. However this probably means it’s a Good Idea™ to find out more about HTML5 at some stage ;-)
Ref: Differences Between HTML and XHTML; Parsing—WhatWG FAQ
Now I have to relearn EVERYTHING!? #
Since HTML5 is mainly a well-defined HTML4/XHTML 1, and because both HTML- and XHTML-style syntax is allowed, you need to do very little (maybe only a
doctypechange) to change current well-made pages into HTML5. While there are certainly new things to learn, we all like learning, right?
Ref: HTML5 differences from HTML4—W3C Working Draft
HTML5 means back to tag soup #
While the XML strictness in XHTML 1.0 and 1.1 certainly encouraged a move away from the bad old ways of the past, there’s nothing in HTML5 (or HTML4 either) that stops you from adding closing elements, correctly nesting elements, using elements appropriately, and generally making good code. HTML5 is forgiving of mistakes, but you don’t have to make them :) Current HTML5 validators are also already good (W3C, Validator.nu), and there is even talk of making a user-selectable ‘strict validator mode’, so if you want to write good code there’s nothing to stop you.
Ref: Why does HTML5 legitimise tag soup?—WhatWG FAQ
HTML5 means ALL-CAPS element names #
HTML5 is case-insensitive; both upper- and lower-case elements are permitted, even
<!doctype html>;-) Note that
<!DOCTYPE html>is recommended just in case you ever need to use it in XHTML (which is case-sensitive).
But I like XHTML-style closing slashes #
No one will take them away from you! XHTML-style closing slashes on empty elements are valid HTML5, so you can write either HTML-style or XHTML-style HTML5 (although it’d be best to consciously choose one and stick to it).
Ref: Should I close empty elements with /> or >?—WhatWG FAQ
HTML5 contains presentational elements #
Some ‘presentational’ elements such as
<i>from HTML4 have been retained. This is because they now have defined semantic meaning—legalese (‘small print’) and
a span of text in an alternate voice or mood, like a word from another language, respectively.
A few of the new structural elements such as
<footer>can also be perceived as presentational, however the use of these elements should be dictated by their content and not their placement.
HTML5 isn’t as strict/pure/semantic as XHTML1.x #
Also “HTML validators aren’t as strict as the XHTML validator”. While HTML5 is more forgiving of mistakes than XHTML sent with a XML mime type, almost everyone used the
text/htmlmime type, and in that case XHTML was treated as strictly as HTML4 (or HTML5) by browsers. HTML5 actually defines element semantics more precisely than XHTML 1, and adds new semantic meanings (for
<i>etc) and elements (
<nav>etc). HTML5 is also much more precisely defined, enabling better conformance checkers to be created, and current HTML5 validators (W3C, Validator.nu) actually seem to be a little stricter than the XHTML 1 validator.
Ref: the differences between HTML and XHTML—WhatWG FAQ
HTML5 is only what ‘Supreme Dictator for Life’ Ian Hickson deigns to accept #
The WhatWG and the W3C HTML5 working group are using a different process to most other W3 projects—rather than the traditional ‘black box’ approach they accept input from anyone willing to give it, and decisions are not reached via consensus member voting. While this may seem to some like Hixie is basically playing god, he is actually working hard to base the spec on reality and achieve consensus with implementors, as they have the final say on what is implemented. So actually it would be more accurate to say HTML5 is what the browser makers accept.
Despite the exclusionary image some have, Hixie and other WhatWG & W3 HTML WG members read through and respond to a massive amount of feedback, via the WhatWG email list and W3 HTML email list, IRC, the bug tracker, and even weblog comments. In my experience they have been open to (and frequently requested) improvements. If you have some feedback, by all means engage with the HTML5 community (preferably after having checked the official FAQ), giving examples of real-world usage and the pros and cons for your idea. If something is confusing ask for more information in a mailing list, or even better in IRC.