Death To The Div

Every web developer is looking forward to the new HTML spec, HTML 5. The new spec will birth 20 new elements to add more underlying semantic meaning to content. The new elements came out of popular IDs and Class attributes for common situations in web design: <nav> is just like <div id=”nav”>. But these new elements are just a stop gap.

Death to the Div Tag

I wish the web community could move beyond pigeon-holing ourselves with specific elements. Why can’t we make our own elements to better describe our content? If I had my way <div>s would be ancient history and any element not already defined in the HTML spec would be treated by browsers like a <div>.

There are many benefits to opening up the element nomenclature like this.

1) It will be much easier to describe content. No longer will we need to shoehorn our content into quasi-relevant elements. Did you know the <address> tag is to define the contact information for the author or owner of a document and not to hold a plain street address?

2) No more div-itis. Web developers will no longer have to wade through a dozen </div> tags. <div> tags are the least-semantic structural elements in a web designers toolbox; it literally means ‘division’ of a page and is used to mark off different sections within a document. Things can get pretty messy when using too many <div>s however as it is hard to tell where they end. Take a look at this code example:

<div id="container">
   <div id="article">
      ...
     <div id="chart">
      ...
     </div>
   </div>
</div>

Look how much better this markup looks from both a readability and maintainability perspective:

<container>
   <article>
      ...
     <chart>
      ...
     </chart>
   </article>
</container>

A benefit to free-form elements is the semantic closing tags making it clear where each element begins and ends.

3) Microformats might actually work. The movement to create semantic markup using loosely agreed upon Classes slowly died off due to the extra bloat it introduced to the underlying code. With the ability to create your own tags, Microformats could flourish and we can begin to set-up our own best practices for describing content.

4) Faster JavaScript. Not many browsers support the JavaScript method getElementsByClassName but every browser supports getElementsByTagName. Because of this many libraries have had to write their own implementations which are many times slower than native methods. Faster DOM traversal = faster JavaScript!

What will it take to make this a reality? Boogers

We’re already going to have issues with older browsers supporting brand new elements with HTML 5. We might as well go all the way and make sure every browser can support whatever element we can come up with. After all we only have one shot to get HTML right for this generation according to John Allsopp.

Many browsers already support free-form elements both with CSS and JavaScript. To really flesh this out I created the Booger Test and below are my findings.

  • Firefox 3+ supports the <booger> tag as if it were a native element but has to be explicitly set to display:block.
  • Firefox 2 has no problem with CSS unless there children elements in which case the <booger> tag collapses. Weird!
  • All versions of Internet Explorer don’t know what to do with the <booger> tag but they do function normally when using a JavaScript shiv
  • Safari and Chrome have no problems.
  • Every browser I tested passed the JavaScript portions (getElementsByTagName(“booger”)) of the booger test with flying colors!

So as you can see, we are really close to being able to use our own elements. HTML 5 is already going in this direction but it would be a real shame if everyone got hung up on what frivolous new element names we should all agree to use instead of coming up with new functionality to move the capabilities of the web forward.

67 Responses to “ Death To The Div ”

  1. I wonder if a more feasible solution might just be to have a mode for html editors/viewers to display any <div> with an id/class a different way.

    For example:
    <div id=”article”>
    would show:
    <#article>

    And
    <div class=”header”>
    would show
    <.header>

    I’m unsure how it would handle multiple ones of these, such as:
    <div id=”article” class=”centered”>
    Perhaps
    <#article.centered>

    For multiple classes
    <div class=”class1 class2″>
    This would be nice:
    <.class1.class2>

    But I’m afraid that might not work so well since period is valid in a CSS class name.

    This seems a suggestion that is actually doable since you can implement it on your own and it doesn’t really make any difference to the final generated source. Unfortunately, it loses some of your intended benefits, like being able to use getElementsByTagName and using the element names in CSS (though that last one isn’t so bad, since you can still use the pseudo-names in the CSS like #article and .header). You also have the downside that you can’t XPATH doesn’t understand an expression like “/body/#article/#section/.rightcolumn” so you’d have to write it out using all the divs or something like ‘/body/*[@id=”article”]/*[@id=”section”]/*[@class=”rightcolumn”]’ and that’s fairly nasty.

    Any takers? Or is it no longer worth the effort?

    Reply

    JP responded on July 4th, 2010:

    Forgot to include – this wouldn’t just be a way for the html viewer/editor to display the source. You could also type in your code in the pseudo form and it would translate it behind the scenes.

  2. I think the problem is that there is so much information about DIVs and as a result so easy to learn. I found your post very interesting and will inform my members about this post!

    Reply

  3. “it would be a real shame if everyone got hung up on what frivolous new element names we should all agree to use instead of coming up with new functionality to move the capabilities of the web forward.”

    Agreed 100% – what can I say, full support of custom elements across all browsers would be fantastic, and most certainly the way forward IMHO.

    Ioan – IDW

    Reply

    Russell Heimlich responded on November 17th, 2010:

    We’re almost there. If we can just get IE to hop on board…

  4. Do you think its the death of the div, but why there are still many sites still using it?

    Reply

    Russell Heimlich responded on January 21st, 2011:

    I think Divs should die they’re nowhere near their deathbed as of now.

  5. Haha I love the knife over the div….

    I don’t think its going away anytime soon…although these people do:

    http://deathofthediv.com/

    I think HTML5 has just changed the usefulness of the div, it’s no longer necessary for many things and only useful for some now…like wrapping pages and such.

    Reply

  6. This was very helpful – I will surely recommend this to my friends.

    Reply

  7. Great post guys.

    Reply

  8. […] HTML5 Replace Divs? Here are some useful articles on this topic: http://www.russellheimlich.com.....o-the-div/ http://www.w3.org/TR/html5-diff/#new-elements It seems like the header, footer, nav, section, and […]

  9. You completed a few fine points there. I did a search on the issue and found nearly all folks will have the same opinion with your blog.

    Reply

  10. hi this is a very intresting website and collection of information and data on thoses sharing my sirname.

    Reply

  11. Although I actually agree with what you’re saying, we still have the “problem” that’s called legacy. How (for example) would a “new” browser interpret badly formatted (like no doctype, or wrong doctype) HTML, which contains a font tag?

    Would the browser treat it as a “fake div”? And thus a block level item…

    The problem here is not that you’re completely right (you are), it’s just the fact that 99% of the code out there is so excruciatingly bad that it will cause problems.

    It probably boils down to: “Are we willing to potentially sacrifice everything ever created, for a great future?”, it’s kind of a black/white statement, but you get what I’m saying.

    Reply

    Russell Heimlich responded on February 16th, 2012:

    A new browser would still recognize the element and treat them the same way they have always treated them. All I’m saying is that if there is an element the browser doesn’t recognize, then treat it like a block-level plain old element.

    Other than that, there would be no problem what so ever with backward compatibility.

  12. Death To The Div » Coding, CSS/HTML, Rant » Russell Heimlich I was recommended this web site by my cousin. I am not sure whether this post is written by him as no one else know such detailed about my trouble. You are amazing! Thanks! your article about Death To The Div » Coding, CSS/HTML, Rant » Russell HeimlichBest Regards Nick

    Reply

Leave a Comment of Your Own