12 common problems with HTML5
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.
Ref: When will we be able to start using these new features?—WhatWG FAQ
IE doesn’t support HTML 5
Ref: What about Microsoft and Internet Explorer?—WhatWG FAQ
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? ;-)
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
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
doctypechange) 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
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
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).
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
HTML 5 contains presentational elements
Some ‘presentational’ elements such as
<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
<footer>can also be perceived as presentational, however the use of these elements should be dictated by their content and not their placement.
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/htmlmime 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
<i>etc) and elements (
<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
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.
- ohlookitskiki likes this
- athales likes this
- psdtohtmlshop reblogged this from boblet
- xmyfuckingmurderx reblogged this from boblet
- issuetracking likes this
- ginoepina likes this
- voyage-argentine likes this
- reparation-iphone-france likes this
- defibrillateur likes this
- maudeson23 likes this
- location-en-corse likes this
- axooh likes this
- ines-schneider likes this
- 90srock likes this
- hober likes this
- kaminoaki likes this
- webbunny likes this
- fleetingftw likes this
- lda likes this
- jayrobinson likes this
- boblet posted this