By Craig Buckler

5 Things I Hate About HTML5

By Craig Buckler

I love HTML5. So does Viki Hoo and her recent article, 5 Things I Love About HTML5, states why. But not all is rosy in the HTML5 garden. So, in order to restore balance to the SitePoint universe, here are my five pet peeves:

1. Superfluous Tags

HTML5 (the technology) provides 30 new tags although you’ll never use half of them. That’s fine, but consider how we coded navigation lists in HTML4/XHTML1:

<ul id="nav">
	<li><a href="link1.html">link 1</a></li>
	<li><a href="link2.html">link 2</a></li>
	<li><a href="link3.html">link 3</a></li>

Here’s the HTML5 equivalent:

		<li><a href="link1.html">link 1</a></li>
		<li><a href="link2.html">link 2</a></li>
		<li><a href="link3.html">link 3</a></li>

It has a small semantic advantage, but does it really make a difference in the real world? No.

It also has the disadvantage of increasing page weight and adding unnecessary DOM elements. I’m using the new syntax but, after many years of extolling the benefits of clean code and avoiding DIVitis, it makes me feel a little dirty.

2. Poor Developer Tools

Does your IDE or editor fully support HTML5, CSS3 and the new JavaScript APIs? I bet it doesn’t.

In the old days, I loved using Firefox extensions such as HTML Validator which highlighted issues in your mark-up when you viewed a page. Today, we have a few HTML5 validation tools, but they’re usually buggy beta releases and you need to submit your code to an online service. It’s slow and cumbersome — I rarely bother.

3. Multiple Media Madness

The new video and audio tags are great. Unfortunately, the ongoing vendor battles mean your video must be encoded in WebM, H.264 and Ogg Theora to work in HTML5 browsers. Oh yes, you’ll then require a Flash fallback for IE6/7/8 — and if you’re doing that, why bother with the video tag?

4. Browser Support

I could rant about IE6/7/8 and IE9/10 not being released on Windows XP. However, in my opinion, it’s the diverse range of implementation levels that annoy me most. If you want to use a HTML5 feature, you must continually consult documentation and test code thoroughly.

Consider something as basic as the date input field. Opera shows a lovely calendar picker. Firefox, Chrome and Safari know a date’s required, but offer rudimentary controls and validation. IE9 falls back to a dumb text box. Ironically, you’ll probably want to disable Opera’s implementation and revert to JavaScript solutions.

5. Hype and Confusion

The media pounced on the term “HTML5” and it’s applied to any cool web effect. Even if it’s an animated GIF. While that’s not necessarily a problem when you’re talking to clients, it is causing developer confusion:

  • Some consider HTML5 to be radically different to HTML4 when it’s really an evolution.
  • Some think effects are achieved using HTML when it’s actually CSS3 or JavaScript APIs.
  • Some won’t touch HTML5 because the W3C specifications are still at the draft stage.
  • Some won’t consider HTML5 because they need to support legacy browsers.
  • And let’s not forget the trouble CSS3 vendor prefixes have caused and why we need to fix it.

These concepts may be obvious if you’ve been working in the trade a few years, but who’d want to be a newbie?

Let’s be clear: HTML5’s benefits outweigh the problems. I use it and recommend you switch as soon as possible. But remember that you’re paying a price to use cutting-edge techniques; don’t assume code will work as you expect on every HTML5-aware browser!

  • USPaperchaser

    #6 W3C needs to dissolve.

  • Lance

    Really, “W3C specifications are still at the draft stage” sums up most of the points.

    HTML5 is the New World and those that work here are Columbus. Some are even the Vikings: using HTML5 without even knowing it.

    Inherent to all trail blazing is a lack of a proven, tested path. Many paths will end up dead ends, or worse, contain “dragons”. These 5 are certainly some of the growing pains the concept must solve before living up to it’s potential.

  • Which IDEs do not support HTML5? I know that Komodo, Netbeans, and Webstorm has really good HTML5 support. Haven’t really looked at others but if you have 3 good choices why go further with your old IDE that lacks the support for the stuff that you do? Even text editors like Sublime Text and Vim (with plugins) has great support for HTML5 and CSS3.

  • Increases the page weight? By what, 2 characters? ‘[nav][/nav]’ vs. adding ‘ id=”nav”‘?

    Plus, as stated, you have the semantic benefits of external parsers and spiders now knowing that a given section contains the nav or article or whatever. (Which you don’t get with the raw UL/id trick.)

    And actually, I’m not part of the absolute minimum markup crowd. Heck, even zenGarden, the original poster child for the CSS crowd, added extra divs and spans here and there in their layout. Why? Because it made generating new designs and layouts from the existing pages much, much easier.

    Assuming that your current layout is the end-all-and-be-all of design and will never change is — in my book — being more than a little short-sighted. And going back and editing 5,000 pages all because you originally decided that this layout didn’t need a container div is little more than drudgery.

    Unless, of course, you’re billing by the hour. Then feel free.

  • Adam westbrook

    The blazingly simple answer to number 1 is to simply stop using ul! What’s more semantic than a nav element with child links? If you’re relying on the li tags for styling you’re doing it wrong…

  • Re: the vendor prefixes.

    Every since I discovered this, I haven’t used a single vendor prefix. It’s friggin’ genius.

  • “Does your IDE or editor fully support HTML5, CSS3 and the new JavaScript APIs?”
    No, because they are not a GA (“stable”) release, so why would an IDE support something that might still change?

    “… you’ll then require a Flash fallback for IE6/7/8”
    Sure, let’s code fallbacks forever, let’s not change one thing, ever, MSIE6 FTW!

    “Browser support” is a vendor issue, not a HTML5, CSS3 or whatever problem. Browsers must at least implement what W3 defines as the standard, and HTML5 will be a standard.

    Your only valid points are #1 and #5 and even so, #1 may not make sense NOW, but I’m sure it’s done like that for a reason, have a little faith. About #5 how is that HTML5’s “fault”? Same thing happened to AJAX (which doesn’t even exist, it’s only Javascript), so if the media and even the dev community is stupid let’s educate them and not blocking new technologies.

    I’m sorry, but this was, IMHO, a very unfortunate and silly article.

  • Greg

    Lance: Well put.

    To be totally honest, you should not be looking at using HTML5 for mainline websites, or trying to mould website using javasript to “Support” HTML5, rather think of smartphone apps, and native apps that support HTML5 forward progressing technology, HTML5 is awesome for such use, I wouldnt build an “HTML5” website, nada.

    As lance put, there are teething problem, infact any new technology has teething problems, infact rather thing about how many “teething problems” IE6,7,8 include 9 have had and never been resolved.

    HTML5 is not a “product” as such, it’s a progressing technology, i’m totally excited about where it’s going.

  • Greg

    Just one small thing I noticed on your browser support.

    If you’re still supporting IE6, you (or your company) is not progressing.

    If we do a website, we simply dont support it. If the client insists, then it’s not a client we want.

    • So progress is about breaking sites on a subset of browsers?

      Surely progress means supporting any device/browser, especially now we have responsive design? They may look completely different, but that’s PROGRESSive enhancement.

      • Tony

        Great article Craig (loved the other one too).

        With all due respect, I have to say that I totally agree with Greg regarding supporting legacy IE browsers as low as IE6. We all know that they are out of date and there’s no *real* reason why anyone can’t upgrade to the latest versions. Anyone still using XP is way behind now too – and before anyone says it, I understand that some older companies with 100’s of desktops might not be able to afford to. However, I don’t believe it should be our responsibility to “carry” these – especially when many of the browser updates for IE were for “security” holes. In my humble opinion, the web developer/designer community continuing to support the legacy IE browsers is like saying “its still OK to use them”. Technology moves on and for everyone to get the benefit, they have to move on too.

        I generally support a “window” of IE browsers when developing sites. I don’t support IE6, but I do still support IE7 and IE8. When IE10 is fully out, I’ll consider not supporting IE7 and so on…

        I don’t believe that we can continue to support every device and browser as it just makes the whole process of coding a website take even longer. Apart from the frustration of having to hack some code to make that beautiful layout work in an older browser (and having to keep/find older versions of every browser to test your work), the whole idea is income limiting; so even if you charge more because you have to do this, your time will be spent doing just that, instead of moving on to your next project more quickly. Your next client suffers too, as they’re in the queue behind this one!

        There’s no easy answer, is there?

      • IE6/7 is only a problem if you make it one. For websites, I rarely give it more than a cursory glance. IE6 may look crap but, if the content’s usable, I’m happy with that.

        IE6/7 is only an issue if you’re striving for pixel-perfection. You’ll end up using a multitude of shims and, ultimately, it’s futile.

  • Craig, I know these kinds of posts come in pairs and countering your “I love” one with this is only appropriate. However, I think it goes without saying that these MASSIVE changes come in stages. We might not like the “superfluous” tags or whatever, but these are merely foreshadowing what was probably necessary to acquire what we one day will have (whatever that might lead to with all this techno stuff).

  • #1: No advantage yet. Sometime (somewhere) in the future maybe Screenreaders will be intelligent, eventually. Hopefully.
    #2: All the major editors have plugins/syntax files for the new HTML5-elements and attributes. Validators… true – good point.
    #3: Why? Mobile. CPU. And you can omit OGG/Theora by now (only for FF3.6 afaik)
    #4: Oh boy. So true.
    #5: Talking about confusion in an HTML5 post and then ranting about CSS3 vendor-prefixes. Way to go ;-) Clients will never get the difference if we don’t teach them.

  • DeadWolf

    With #2, It’s a problem with the IDE vendor, not HTML 5. In this whole article, you sound like someone complaining that the top of the line game won’t run on their ten year old computer. For technology to evolve you must evolve with it. Do we need another “Quirks mode” browser because whiny developers refused to change?

    I’m surprised that SitePoint allows bogus articles like this to get posted. I guess anyone can claim to be a developer these days. Use enough buzz words, you can blog all you want.

  • Mike K.

    Regarding your third point. Flash for IE, HTML5 for mobile. Makes complete sense.

    • If only. The desktop browsers support different codecs.

  • Re #1

    One word: accessibility. Firefox exposes the nav as navigation to AT. Your old pattern must have an ARIA role to be equal. And then it is not as lean anymore.

    That is not a “small” semantic advantage in my book.

    • Lars, half a word, IE – it doesn’t expose the nav to AT – and since many users still use IE that makes things difficult.

  • Brian

    Great article. Although your example of superfluous tags makes the assumption that all navigation has to be based on lists.

  • Great article. Couldn’t agree more with the IE issues. When I have to use IE, at home I’m on ie10, at work ie9, my fellow team members/other employees run ie8 (for some reason) and my boss runs in ie9 comp mode. It literally takes longer for me to x-ie test and add in shim/polys than to create the original markup.

    And trying to get other developers to upgrade is met with the “yea but how will we see how it’s being seen by people using IE8?”. (f12 in ie9+?) It’s like everyone is just stuck. Personally, I feel it all boils down to xp users not being able to upgrade. If the xp-based computer works, why upgrade? If they can’t find a reason, then they probably can’t fathom another browser beyond IE anyways… *head in hands*

  • stevo

    HTML5 is not going to become a specification until at least 2014. As it stands it’s a huge step backwards in any sort of standardisation. Apparently they want monkeys to be able to mark up web pages that validate.

    Couple that the possible re-ignition of the browser wars with the vendor prefix issues and things like google’s Dart and apple’s refusal to allow Flash and I have to agree with another comment – get rid of the w3c cause they are not doing anything productive in a timely manner

  • Dan Norman

    I liked this article for what it’s what it’s worth and I’m always puzzled when people take the content so personally (or attack personally as a result of it).

    Point 3 is especially valid. Providing a Flash fallback doesn’t feel like progress when (until iOS) you could use Flash in isolation and cater for 99% of your audience.

    That said, I love HTML5, CSS3, JQuery and, yes, I love the W3C – there I said it!

    • Don’t forget that iOS accounts for a very small proportion of users. At best, we’re talking about 20% of mobile devices which account for 8% of all web activity, i.e. 1.6% — fewer users than IE6.

      I suspect people think it’s more because the iPhone/iPad have an exaggerated representation on the web and among developers. Unless you’re specifically targeting iOS users, Flash remains the most reliable technology for cross-browser video support.

  • Hi,Craig,
    I have read your article very carefully, it is a very good post.
    Now I have a more impartial perspective to look HTML5 and HTML5 development.
    Thank you very much.

  • Hi,Craig,
    I have read your article very carefully, it is a very good article.
    After reading your article, I have a clearer understanding of HTML5 and HTML5 development.
    Thank you very much.

  • Except that the nav element is not what you make of it: an ul element in disguise.

    It may be that your resistance to learn is taking over and makes the nav element superfluous.

    The ul element is just a block element, while nav is an entire section.

    A technical excerpt form the specs :

    The nav element represents […] a section with navigation links.


    A nav element doesn’t have to contain a list, it can contain other kinds of content as well.

    • If nav can contain other types of content, then what’s the point of it?!
      I understand what you’re saying, but I bet most of your sites use a child list.

      • “Craig Buckler” you are right. I also think these extra tags are not very useful.

      • Wohh I didn’t say they weren’t useful! I’m more than happy to use article, section, header, footer, nav etc. where I would have previously used a div. I’m just uncomfortable when they’re used in addition to the existing structure.

      • Basically: when I put links in nav, I don’t have to throw wrapping elements around them. Any other element element, beside links, means overkill, unless the content in the nav element, is complex enough to demand another semantical construction. A simple enumeration of a few links is not.

        Simple menus or multilevel menus spells out lists. Notice the difference: menus, nav.

        And it doesn’t mean it was the right choice. Lists are used in menus because they degraded in a comprehensible way. Lists are used in menus for structure, and not for semantical needs. Lists replaced divs in menus and that was regarded as a semantical win. Is it?

        What is a link? A piece of content, inside an anchor element.

        What is nav? A section with links, piece of content, inside anchor element.

        When I put links in nav, the content in them is already well delimited. Automatically wrapping lists around them is overkill. Or a habit gone bad.

        When do I think about putting other elements in the nav element? When my nav content starts telling a story. That is, when I have enough links to semantically structure that story. And using lists for that is but one way to tell that story.

        When do I think about wrapping lists around links in nav? Only when is semantically viable. Which may be never. A list element has a place wrapping links only when is semantically required.

  • Nice Article…
    IE browser developer need to work hard for better result like Chrome and Firefox……

  • As for #2 and validators, there’s an actively maintained, cross-platform command line version of Tidy available on Github:

    It’s beta / experimental, but you’re welcome to contribute just as everyone else. I don’t know C, but already had a feeble attempt to submit a pull request and opened a handful of issues to kick off discussions, which is precisely a way to move things forward and not ranting in a blog post without any constructive alternatives brought up.

    As for #4, I hope you were just joking about disabling Opera’s date picker, this is precisely what Modernizr is for. Combined with Yepnope.js you can even forgo loading your JS date picker if there’s a native one, saving on bandwidth!

  • I really like HTML5 as an evolution of HTML. What really bothers me is WHY do I have to put an extra meta tag for HTML5/CSS3 to work on IE9?

  • TehYoyo

    I’m actually kind of mad that you didn’t mention anything about the loose practices that W3C HTML5 validation allows…it’s really a step backwards, imo, and something that has been discussed in great detail on the Forums.

    • HTML4 allowed loose practices. In reality, so did XHTML1.0 – none of the browsers cared if you left off a closing p tag or whatever.

      Browsers will always attempt to render what they think is best — not necessarily what you wrote. It can be a pain, but it’s been that way since day one and isn’t a specific HTML5 problem.

      Don’t get mad. If you don’t like it, don’t do it!

      • I was introduced to XHTML in 2007. As far as I am concern it is very strict compared to any version of HTML. In spite of what the over zealot college instructor preached, you are absolutely right about the relaxed rules towards missing closing tags.

  • hi,Craig,
    Thanks for your good post.
    After reading your 5 Things I Hate About HTML5, I have a more clearer understanding about HTML5.

  • Many problems are facing developers but we always have to move on. I bet one year from now, IDEs and browsers will support most of HTML5/CSS3 specifications.

  • Lets face it – it’ll never EVER be perfect – as much as I hate the extra work, in the 15 years I have been doing web development – the discussons about incompatibility of devices, OS, browsers, Scripts and plugins has never stopped – that’s the nature of software being developed on different timelines, rules, laws, budgets and dev’ skills. It’s an unfortunate (but exciting at times and interesting) part of our industry !!

    (But it would be nice for once to code a site and it KNOW it will just works across the board … I can see the pigs flying).

  • While I see, and applaud, the semantic relevance to the new html5 tags, their use is still being worked out.

    Recently Googled “basic html5 structure” and found ~4 different well thought out approaches, completely different, with quotes from the spec supporting each.

    There are still lots of limitations. Changing my basic choices now would be premature. While it is the future, the standard is still in flux.

    I don’t want to bet on the Blockbuster of the group.

  • Lucas

    I think the most significant is #5 – the hype surrounding the word “HTML5”.

    I have seen it in job quotes already, where agencies get the job by creating web pages in HTML5, when the only difference in the final job was a div changed to a nav.

    I think it is a little dangerous to get rid of the central body that is trying to standardise everything. Without standards, who knows how many directions browsers will go.

    As soon as the hype dies down and everything is logically standardised, then technologies will follow. The hype and insecurity of not having a standard is what is holding everything back.

  • Informative one, especially when there are a zillion accolades for HTML5 on the web.

    Well Craig I guess these 5 points are bound to happen as and when any new version is released. I somehow feel the word ‘Hate’ is an overstatement. I’m sorry but right from 1 -5, it seems each of it is forced into as a deterrent and does not justify fully.

    HTML5 is definitely a giant leap and the real benefits would be felt only after a little while when the browsers come to a consensus. Is Microsoft listening?

    • “Hate” is a little strong and I certainly don’t hate HTML5.

      Microsoft is listening. They’ve jumped on the HTML5 bandwagon feet-first. IE9 was an important step, but IE10 looks very good and it’s a first-class development technology in Windows 8.

      • slawek22

        You really mind that?

        We, web developers should all discourage everyone we can from using IE. MS won’t provide new versions of the browsers for old OSes… so it’s just a way of sucking users money and profiting on our work. I have nothing against someone profiting on my work… i don’t care but it’s something like “internet tax”… not only MS is profiting on my work … but it is making my work a pain and that gets me mad. Actually i can’t write modern, fast code because i have to deal with IE crap and people like you saying “IE10 is good” will prolong this sick situation.

        So we have millions of users lingering on IE6-8, don’t you think it should stop? IE10 is maybe “reasonable” implementation? So what? In 5 years it’ll be same crap as IE6 now and we’ll again have millions of users sitting on IE10 because there’ll be no new versions for Win7.

        Actually it’s happening with IE10 right now. No IE10 for Win7… so users will need to stick to IE9 which is a total CRAP. Maybe better tell them to pick ANYTHING else (O, C, FF… doesn’t really matter) right now, because IE is just broken by design?

  • Did you try “cse HTML validator”? If not, you will be very surprised.

  • slawek22

    Wow, Craig…
    Someone on SP finally realized that using VIDEO tag is no good beside fallback … from Flash VIDEO. I thought this time will never come as there are plenty of idiots out there actually RECOMMENDING encoding videos in 3 formats just to provide some half-baked, bugged playback.

    I mean come on Flash adoption rate is 98% and you can provide VIDEO if you care about Apple. You really don’t have to be a genius to realize that.

    And yes, the tag doesn’t support bandwidtch adjstment nor DRM, subtitles, markers and 1000 other things needed for modern video or VOD…

    Semantic web … it’s a bullshit. Changing UL to NAV won’t help you automatically analyze the page in any way.

  • fjpoblam

    I’m with you. On #5, if I understand you correctly, there’s a variant I especially despise: evangelism. HTML5 evangelists seem so strict and opinionated about “their” language and the “meaning and intent” of each semantic element, they seem to neglect to allow for alternate methods in which these elements may be used to advantage. “Ooo no that’s not *correct*!” “You *have to* use a section whenever there’s a header!” “Yes, that’s what the W3C says, but *they’re* wrong.” And on, and on…

  • I think the thing that I hate the most is that its actually necessary to use the HTML5 shim just so your elements will work in IE.

Get the latest in Front-end, once a week, for free.