@boblet

lest I forget (Oli Studholme)

12 common problems with HTML5

Note: I’ve moved all my HTML5 articles to http://oli.jp/, so I can walk the walk. I’ll leave this here for posterity, but won’t update it.
→ Go to: “12 common problems with HTML5” on oli.jp

In-page navigation

  1. Browsers don’t support HTML 5
  2. IE doesn’t support HTML 5
  3. HTML 5 won’t be ready until 2022!?
  4. You mean XHTML isn’t the future!?
  5. Now I have to relearn EVERYTHING!?
  6. The HTML 5 spec isn’t understandable/is overly complex
  7. HTML 5 means back to tag soup
  8. HTML 5 means ALL-CAPS element names
  9. But I like XHTML-style closing slashes
  10. HTML 5 contains presentational elements
  11. HTML 5 isn’t as strict/pure/semantic as XHTML 1.x
  12. HTML 5 is only what ‘Supreme Dictator for Life’ Ian Hickson deigns to accept

Recently I’ve been reading a lot of articles on HTML 5 (such as on Zeldman.com and HTML 5 Doctor), and have seen a few reoccurring false perceptions in the comments. While some may seem funny for those following HTML 5’s progress closely, a lot of people aren’t, nor can they be expected to.

So in addition to the WhatWG FAQ, here are some common misunderstandings (and their explanations), written at a less technical level. My apologies for any overuse of the interrobang :)

  1. Browsers don’t support HTML 5 #

    While a lot of the new stuff in HTML 5 isn’t widely supported, it’s important to remember one of HTML 5’s core principles is compatibility, eg with current content. Apart from a few minor differences most of the HTML 4/XHTML 1 spec is in HTML 5. For the new parts of HTML 5 (such as structural elements) support can often be added today via CSS and Javascript. Finally, modern browsers (and even IE) are implementing the HTML 5 spec now. While full compliance will take a while, there’s a lot that’s already usable, and support is increasing.

    Ref: When will we be able to start using these new features?—WhatWG FAQ

  2. IE doesn’t support HTML 5

    Internet Explorer is something of a … rugged individualist, resisting ‘trends’ (like standards support) and doing things it’s own way (cough .EOT cough) ;-). However as stated above because HTML 5 is mainly a well-defined HTML 4/XHTML 1 with sprinkles, all of the ‘old stuff’ still works. Unfortunately due to bugs, IE currently requires a Javascript hack to use new HTML 5 structural elements. For other new parts of the spec, Microsoft has been largely silent, but the IE team has already implemented Cross-origin resource sharing and Web storage in IE8 (IE Team blog), which were both parts of HTML 5 (and have been subsequently released as stand-alone specs). We can only hope that their well-deserved pride in implementing CSS2.1 completely carries over to HTML 5 and other specs.

    Ref: What about Microsoft and Internet Explorer?—WhatWG FAQ

  3. HTML 5 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 HTML 4, 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 HTML 5, and the rest is backwards compatible.

    Ref: When will HTML 5 be finished? and When will we be able to start using these new features?—WhatWG FAQ, and for fun Is HTML 5 Ready Yet? and Is HTML 5 Ready? ;-)

  4. 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 HTML 5 at some stage ;-)

    Ref: Differences Between HTML and XHTML; Parsing—WhatWG FAQ

  5. Now I have to relearn EVERYTHING!?

    Since HTML 5 is mainly a well-defined HTML 4/XHTML 1, and because both HTML- and XHTML-style syntax is allowed, you need to do very little (maybe only a doctype change) to change current well-made pages into HTML 5. While there are certainly new things to learn, we all like learning, right?

    Ref: HTML 5 differences from HTML 4—W3C Working Draft

  6. The HTML 5 spec isn’t understandable/is overly complex

    The HTML 5 spec is being written primarily for ‘implementors’—programmers who make web browsers and other tools to use the web. Unlike previous specifications, HTML 5 is defining processing steps and error handling explicitly, which can be a little overwhelming if you’re not a browser programmer :) Luckily a majority of the spec is actually just the HTML 4/XHTML 1 you already know.

    Also, there are already many useful articles and resources for author information on HTML 5, such as “A Preview of HTML 5” by Lachlan Hunt on A List Apart, “HTML 5 Reference” by Lachlan Hunt (a version of the spec specifically for authors) on w3.org, “HTML 5: The Markup Language” by Mike™ Smith (a pared down spec that removes implementor details) on w3.org, and sites like HTML 5 Doctor. You can also check out my humble HTML 5 articles :)

  7. HTML 5 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 HTML 5 (or HTML 4 either) that stops you from adding closing elements, correctly nesting elements, using elements appropriately, and generally making good code. HTML 5 is forgiving of mistakes, but you don’t have to make them :) Current HTML 5 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

  8. HTML 5 means ALL-CAPS element names

    HTML 5 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).

  9. But I like XHTML-style closing slashes

    No one will take them away from you! XHTML-style closing slashes on empty elements are valid HTML 5, so you can write either HTML-style or XHTML-style HTML 5 (although it’d be best to consciously choose one and stick to it).

    Ref: Should I close empty elements with /> or >?—WhatWG FAQ

  10. HTML 5 contains presentational elements

    Some ‘presentational’ elements such as <small> and <i> from HTML 4 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 <aside> and <footer> can also be perceived as presentational, however the use of these elements should be dictated by their content and not their placement.

    Ref: Why are some presentational elements like <b>, <i> and <small> still included?—WhatWG FAQ

  11. HTML 5 isn’t as strict/pure/semantic as XHTML 1.x

    Also “HTML validators aren’t as strict as the XHTML validator”. While HTML 5 is more forgiving of mistakes than XHTML sent with a XML mime type, almost everyone used the text/html mime type, and in that case XHTML was treated as strictly as HTML 4 (or HTML 5) by browsers. HTML 5 actually defines element semantics more precisely than XHTML 1, and adds new semantic meanings (for <small>, <i> etc) and elements (<article>, <nav> etc). HTML 5 is also much more precisely defined, enabling better conformance checkers to be created, and current HTML 5 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

  12. HTML 5 is only what ‘Supreme Dictator for Life’ Ian Hickson deigns to accept

    The WhatWG and the W3C HTML 5 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 HTML 5 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 HTML 5 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.

    Ref: WhatWG and W3C HTML Working Group

I hope that was of use. If you have any questions, feedback, or have found a mistake, please let me know via Twitter (@boblet)…

Notes

  1. psdtohtmlshop reblogged this from boblet
  2. xmyfuckingmurderx reblogged this from boblet
  3. boblet posted this