By James Edwards

Better Take The Web’s Temperature — It’s Coming Down With Another “itis”

By James Edwards

At the dawn of the standards revolution came the phenomenon of DIV-itis.

It was well-meaning but naïve developers, for whom converting from tables for layout simply meant exchanging every <table> and <td> tag for a corresponding <div>.

Many people even spoke of converting my site from tables to divs, as though that were the only point of it; all the while completely missing the real purpose, of converting from visual to semantic markup.

Then came the lists — lists upon lists upon lists — and with it a new, yet closely-related pandemic, the latter phenomenon of LIST-itis. What started with an inspired idea for adding meaning to navigation lists, became, to some, the miracle cure-all of pseudo-semantic markup, as every possible structure was ratified into lists. Honestly, people built whole sites with almost nothing else!

A Little Bit of History Repeating

And now it’s happening again!

I like to poke around the source-code of interesting sites (always been a bit of a markup-trainspotter that way). But recently I’ve been seeing tremendous over-use of the <section> element, like this real-world example (where I’ve removed the various attributes and inline-markup for simplicity):


But the section element is not a container, and shouldn’t be used to wrap around arbitrary chunks of content, for styling or layout purposes.

To quote the draft specification:

The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element’s contents would be listed explicitly in the document’s outline.

So most of those <section> elements should probably be <div> instead.

Escaping From The Past

I don’t blame anyone for confusion. The draft specification itself is vague or contradictory in many places; it is a draft, after all.

For example, it’s still far from clear what the <article> element is really for. Does it wrap around sections that link to articles? Does it wrap around the content of the article? Does it wrap around the whole page that contains the article? Or is it just for syndication? Exactly what is an article anyway? (And why isn’t there a <content> element?)

Eventually, the spec will have to clarify all its ambiguities; either that, or we’ll end up settling on a bunch of generally-accepted but non-ratified conventions as to what things mean (which would be unfortunate, especially since that’s exactly the kind of thing HTML5 is trying to avoid).

In the meantime, I fear we’ll see more and more enthusiastic-but-premature experiments with HTML5, mistreating its elements to impart confusing or contradictory semantics, or as physical layout blocks for things that are clearly the job of a <div>.

There seems to be something of a ‘too cool for school’ attitude around the use of <div> in HTML5, like they’re seen as out-dated, unfashionable, crude, or that they shouldn’t be necessary anymore. It’s certainly true that we’ll no longer need them for things that now have specific, semantic elements, such as <header> and <footer>; but for a long time yet, we’re still going to need them as neutral, structural containers. Such containers are critically necessary in web-page and interface construction, still compensating as they do for the near-terminal inability of CSS to define workable, structural layout properties for blocks and pseudo-blocks!

Designing For The Future

I could argue that, in the absence of clearly-defined meaning for the semantics of a new element, it shouldn’t be used at all. Because who are the semantics really for? They’re for access-technologies (like screenreaders), search-engine spiders and other kinds of robot. Yet how can these machine-readers derive interoperable meaning from element semantics, when even the author of those semantics isn’t really sure what they mean?

Oh well. I’m not expecting to change anybody’s mind on this.

So for those of you keen to press ahead with trail-blazing this standard-to-be, I’d simply ask you to remember — not to treat as visual or structural markup, what is really semantic markup.

And beware of SECTION-itis!

  • Mal Curtis

    Why do I get the feeling I know where that real world example came from…

    • Louis Simoneau


    • I couldn’t possibly comment :-P

  • Aaron

    I wish they would go head and come out with HTML5, but alias it doesn’t come out till 2022 or 2021. I am a 13 year old programmer and I am growing up in a new programming age. I am learn HTML5, but I do know HTML4. So please, more HTML5 posts like this! Thanks James Edwards!

    • Patrick Samphire

      Aaron, you can go ahead and use HTML5 right now. As long make sure you use one of the methods to support older browsers (or as long as you don’t actually need to support them), then just do it.

  • Patrick Samphire

    It’s not at all surprising that people are misusing section elements in the same way as they misused divs. These are people who don’t really know what they’re doing with their HTML and CSS, or they’re using CMSs that lack flexibility.

    I don’t actually think that there’s much confusion between sections and articles. I’ve never really found a problem choosing which to use. What I do find a problem with often is whether to use an aside or a section. Content could arguably be either in many cases, and the spec if too vague.

    I think a content element would be even more confusing. Content could be almost anything, and if anything would be even less meaningful than divs (which at least have some meaning).

  • Wilco

    I like your notion of the fact that semantics are mainly there for the machine like consumers of the web (search engines etc).

    This means that, as long as they don’t have a voice, the misuse of elements will continue (you wont hear most of the humans complaining about element abuseas they dont care as long as the website looks ok)

    I guess we need emancipation of the electronic consumers of the web. Perhaps the internet of things or even skynet will change things for then better…

  • Deathshadow

    Welcome to what I’ve been saying for THREE YEARS. So many of HTML 5’s ALLEGEDLY semantic tags seem to exist for the sole purpose of legitimizing the practice of slapping extra containers around PERFECTLY GOOD SEMANTIC TAGS.

    While much of that is to address how many people are too STUPID to figure out how to use numbered heading tags (to the point where in 5 the only one you’ll EVER see used is H1, yeah that’s SUCH an improvement and makes the UA’s job easier — RIGHT) the majority of the specification; at least so far as markup is concerned (and not talking all the other stuff slapped under HTML5’s umbrella that have NOTHING to do with HTML) seems to be crafted ENTIRELY to justify the practice of vomiting up HTML 3.2 and slapping a tranny doctype on it.

    It most certainly was not built for the people who actually embraced semantics, separation of presentation from content, or the dozen other good practices we’ve developed in the decade since STRICT was introduced. In fact, HTML 5’s sole purpose near as I can tell is to set web development practices BACK a decade.

    NOT that the majority of developers have pulled their heads out of 1997’s backside in the first place.

    • Patrick Samphire

      I sympathise to a degree; the loosening of standards allowed by HTML5 depresses me. But, on the other hand, I’ve found sections, articles, headers and footers extremely useful. By forcing myself to use them semantically (not as in the example above), it’s made me think a lot about the way I’m structuring information. What I’m doing now is far more re-usable and meaningful than it was a year ago.

      HTML5 can be misused, and it will be misused, and it is being misused, but not any more so than HTML 4.

      One thing I would say, though, is that with HTML5 I’m not sure I’ll ever be using anything below an h3, though, which does feel kinda odd. Not necessarily bad, but odd. It’s a matter of changing the way I think, from considering headings as providing the structure of the document to using other tags to do so. In some ways, it even makes more sense, because a heading doesn’t be necessity imply structural groupings.

      So, I feel mixed. On one hand, I understand many of your complaints and agree, but on the other, some of the mark-up works nicely for me.

      • Deathshadow

        Because I use headings to make that structure — to me many of those elements are simply extra bloat. The only one that makes ANY sense to me is footer, and even then I’m not sure there’s any reason to make a tag for it that’s separate from DIV. ALL of them are basically redundant to DIV IMHO, and are adding meaning to elements that should already have their own meanings.

        Like putting H1 inside HEADER, at that point you might as well wrap the content of the h1 in B and put a class on both.

        Though people who don’t see what’s wrong with the above sentence will NEVER get what I mean.

      • Patrick Samphire

        I agree that you shouldn’t just wrap an h1 in a HEADER. That’s crazy and pointless. Just as you shouldn’t wrap a single h1 in an hgroup. A HEADER is appropriate when you want to group a bunch of tags that logically form the header of a section or document. For me, that’s useful information.

  • Deathshadow

    Oops, almost forgot.

    That bit about nested lists — it’s reaching absurd levels with the “never use tables for ANYTHING” whackjobs — go to a vBull 4 based forums like Digital Point and hit view source on say… the board index.

    A forum index is inherently tabular data — the data is related by type on columns and record by rows; so why is that endless nested div’s chock full of idiocy ranging from presentational markup, content cloaking and inlined CSS to abuse of endless nested lists on obviously tabular data.

    Hardly a wonder it’s 168k of markup to deliver 16k of plaintext; basically 30k’s job.

    I can’t even figure how ineptitude on that scale is even allowed to be deployed — though it’s a contributing factor to my disgust to the point of nausea with the web development industry as a whole.

  • Nic Parry

    Correct me if I’m wrong, but aren’t we supposed to derive semantic meaning for elements from the class/id names we give them, as well as the actual element we use? kinda makes a lot of HTML 5 elements a bit redundant.

    • Patrick Samphire

      To a degree, but classes and ids aren’t standardized, so the semantic meaning is diluted, and you’re essentially trying to learn or interpret a new scheme on each site. Also, by that argument, you could abandon paragraphs, blockquotes and so on and replace them with divs with classes of paragraph, blockquote, etc. Although some ‘developers’ seem to do that, I can’t think most of us would like to see it.

    • Deathshadow

      Not at all — because there are NO standards for what people call things with their classes and ID’s. As such there is no way for UA’s to figure out what ANY of those classes and ID’s mean.

      Though semantic classes and ID’s, saying what things ARE is still important as that’s just practicing separation of presentation from content. IF it’s in the markup, say what things ARE, not how they appear.

      But in terms of “semantic meaning” from a class? Not so much. It’s good practice, but it’s meaningless from a standards/UA point of view.

  • xhtmlcoder

    That’s a horrendous “real-world” example. Exactly the type of nonsense I’d expect from a lot of people who are trying to use experimental HTML5, without even understanding the basic principles of markup semantics in the first place.

    Whoever wrote that probably needs to go on a ‘web beginners course’ or something, and use a fully normative markup language. Instead of them ‘blindly guessing’ or just slapping meaningless markup around text.

    If they cannot write semantic HTML 4.01 then giving them even more ‘new elements’ to play with; on the whole confuses them even more (as can been seen in the demo).

    • deathshadow

      Your last sentence being EXACTLY where a lot of my problem with HTML5 is — as it stands the majority of developers STILL can’t seem to wrap their heads around simple tags like Label, Legend, Fieldset, TH, Caption…

      Adding MORE tags to the specification at this point is NOT the answer — especially when many of those tags undo the POINT of HTML 4 strict… removing redundancies that confused people. MENU and DIR deprecated for UL for example… or OBJECT supplanting iFrame, bgSound, embed, applet… with even IMG allegedly having been on the chopping block.

      So along comes HTML 5 introducing AUDIO and VIDEO, two tags that are ALSO redundant to object — or CANVAS which is completely useless without javascript, begging the question WHAT THE DEVIL DOES IT NEED A TAG FOR?!?

      HTML5 — everything old we were supposed to be moving away from slapped together any old way. Progress? I think not.

      • The thing with audio and video is that — like canvas — the elements themselves are not the real point; the real point is the format connections they define and the scripting APIs they make available.

        Have you actually tried working with HTML5 audio, for example? It’s a total dream, and so much easier than the kind of multi-format content negotiation that we otherwise have to do.

  • Daquan Wright

    I developer in my opinion is someone who has knowledge to complete a task, through means of research/documentation, consulting others in their field, experimentation, and practice. I always see that using something is easy, but “how” to use it or “when” is what actually matters in the long run.

    HTML5 does give you more freedom. But if you had a strict mindset when using XHTML then you’ll be fine because you’ll be disciplined enough to use elements when appropriate. I am a standards nut, so maybe that’s just me.

    But anything you use a language (whether it’s markup or programming), you should refer back to the documentation if you’re not sure of what a particular feature/function does in a language. Just knowing what something is and its purpose is a great starting point.

    The example obviously shows whoever wrote it is not a disciplined developer.

  • Daquan Wright

    “A” developer*

  • Shane

    Correct me if I am wrong, but from your comments I have read it seems a lot of you would rather have a type like attribute for divs with specific values that are allowed for these new tags instead such as the header and footer?

    Was this something that was considered before?

    • No I don’t think anybody’s saying that.

      Not that there’s exactly much of a consensus here … but I think everyone agrees that the core idea, of creating new semantic elements, is a good one. The questions arise around what elements to create, and what they mean.

      I think a <content> element would be a good idea precisely because it’s unspecific. It would just be a general way of saying “this is the main purpose of the page”, as opposed to the header, footer, sidebar etc. It would surround exactly what we now define as <div id=”content”>

      The problem with <article> is that it’s prejudiced with respect to types of content — it assumes content in the form of blog posts and articles; just like earlier versions of HTML assumed content in the form of academic essays. Give it another decade or 2, when the things we do with the web have evolved again, and maybe the notion of “article” will make as little sense as the notion of “essay” does today.

  • kaf

    you forgot to mention the most insidious of all “itises” …. xml-itis

    Just as we’ve been through “everything must be a div” phase we have also been though “everything must be xml” phase.

    And after we had been faced with config files in apps that were unnecessarily xml this disease turned it’s attention to the web.

    The result is that abortion called xhtml. A so-called standard which served no purpose except to replicate an existing standard which did exactly the same thing thereby unnecessarily splitting the web dev world.

    The sheep who were tricked into embracing xhtml are now paying for it as their standard is dying and they have to switch back to html anyway.

    • Patrick Samphire

      I think that’s going a little far. What most people used as xhtml (xhtml served as html) was a syntactical improvement, because it enforced a degree more discipline in code than the mess that preceded it. All of those xhtml ‘rules’ will still work perfectly well with an html5 doctype, so no one is having to ‘switch back’. In fact, one of the most pertinent criticisms of html5 is that it will allow a complete hodgepodge of coding styles. Which may be great for amateur developers only working on their own sites, but which will be a nightmare elsewhere.

      • Stevie D

        The thing about fauXHTML is that it doesn’t enforce *anything*. Because browsers treat it as HTML, there is no hard line on error recovery – instead of giving a YSOD, browsers just work around any syntactic mistakes, just as they would in HTML Strict or HTML Transitional. Hence the huge number of pages out there pretending to be XHTML that have dozens of errors, if not hundreds.

        Most of the extra ‘discipline’ that XHTML introduces, like taking away the implicit closing tags of and etc, lower case tags and quoted attributes can all be done in good ol’ HTML, if that’s the way you want to do it. And the other bit about requiring spot tags to be closed is IMO nonsense anyway, and makes sense only from a pure XML perspective, not from an HTML one.

      • How does it only make sense from an XML perspective to have stricter parsing rules? HTML’s looseness — the ability to have empty unclosed elements; the optional nature of some attribute quoting; being allowed to omit some closing elements — are all bad things in my book, because they make for a language which is more expensive to parse. XML formedness on the other hand is quick and easy to parse, has no obscure exceptions or arbitrary illogical rules, and is a much better choice because of that.

        fauXHTML offers nothing else, that’s true; but it costs nothing either, and it is better-formed markup. For me, that in itself is good enough reason to use it. However .. real XHTML has loads to offer — and here’s the thing — *it’s the same markup*. So you can serve as XML for UAs that understand it, and do other XML things there; or just serve as text for other UAs, and leave out the extra stuff.

        Granted, the strictness of true XML parsing is a problem for the web — nobody wants their site replaced with a single unfriendly validation warning. But abandoning the entire concept because of that was premature; we should have looked at that, found a better way of handling that situation, not just abandoned the whole concept.

        Oh well, its too late now. But XHTML formedness continues to be a worthwhile thing, and all my HTML5 coding is still in that style. Because it’s simply better — it’s cleaner (than any variety of HTML strict), which makes it cheaper to parse, and easier to syndicate (because XML parsers can read it)

    • It’s not “going a little far”, it’s wrong in every important respect.

      I apologise for using such hyperbole — I don’t often go as far as telling someone they’re “wrong”, but in this case — seriously dude! XML is one of the most important technical innovations of the last 20 years; it has revolutionised information interchange, perhaps more than any single invention since the internet itself. Without XML we would never have had web 2.0, web services and APIs, feeds and syndication … you name it.

      As far as the web goes … well in my view, the re-formulation of HTML as XML was the best thing that ever happened to the web; and the move away from it has been a crying shame. The sheep who were tricked into abandoning it (and the wolves who decried it) are now forcing the entire web to pay the price in non-extensible markup, and the need for a whole new standard to make up for that … which *still* doesn’t solve the central problem (HTML’s lack of extensibility .. which XHTML has)

  • Stevie D

    It isn’t true that the only heading tag you’ll ever see is [h1] … all heading tags remain valid, but the specs allow you to use [section] to structure your document _if you prefer_. You don’t have to – there may be times when you don’t want to to nest loads of [section] elements. Equally, some authors may choose to continue using the various levels of even with [section]s if it makes it easier for them to keep track of the structure of the document.

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