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.
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.
so basically… you like XML.
Sort of. It’s more like a refinement of HTML more so than the strict nature of XML.
Wouldn’t this prevent future specs or browsers from adding new HTML elements with non-div-like behavior? For example, Safari would not have been able to implement canvas if they had to worry about breaking existing valid pages that used “canvas” as a generic block-level tag.
This is certainly the biggest sticking point but would be a good use for doctypes to manage which tags were reserved. Programming issues have these same issues like in JavaScript you can’t have a function named ‘floor’.
This could be managed with namespaces. Then of course Safari would not recognize an opera:canvas and vice versa. Maybe the element’s canvas behavior should be specified in CSS? We will need something like this anyway if we can make up our own elements:
avatar { behavior: image; }
byline { behavior: text; }
graph { behavior: 2d-canvas; }
Ooo I like the way you’re thinking henry.
I came to the same conclusion as henry. Existing HTML tags should have default behavior but unrecognized tags should default to one as well (standardized across browsers of course), perhaps as you suggest as (unstyled) div. (But what if it’s nested in a block where inline content is expected? Maybe span might be a better default.). Then the behavior can be overridden using CSS. You can already override the display function of tags (e.g. display:block, inline, table, table-row, list-item, etc. Of course defining a rule for divs should not affect undefined tags.
Bright ideas expressed, guys. When css works with objects at block organization and text formatting, where’s the need for special tags, when everything is a block with defined behavour!
You just fully independently invented XHTML =) Bravo! =)
He’s not saying invent a language that allows for any tag – XHTML already does that; what the author is calling for is that web browsers be made to understand natively, without any CSS/JS magic, to treat all non-standard tags like they were DIVs.
Personally, I think that is a great idea. No more would I have to give every single DIV an ID or class name, and I wouldn’t have to mark every closing div tag with a comment to say what it’s actually closing.
In doing this though, there should still be a body in charge of the ‘standard’ HTML set of tags, i.e. ‘nav’ being a navigation, ‘article’ for an article, etc; therefore bots would be able to decipher websites intuitively.
Phil nailed it on the head!
so get rid of divs, but allow us to use them liberally under an alias?
Semantics are not about how relevent the content is to the container. There has to be a wider taxonomy so that content has context across the internet which cannot be achieved if every developer uses their own custom tag names. and clearly it fails as a concept when people then name the tags in their own language, obscuring thier meaning even further.
What would be better would be that designers and developers stop thinking in terms of cell based layouts. A lot of people I have seen think that div is just an alias for td. Containing a whole bunch of tags and padding them in to make a tidy gutter instead of styling those tags to be margined is just lazy development and is 80% of the problem.
“Semantics are not about how relevent the content is to the container.”
So what is all the hoopla about <nav>,<article>, and <section> then?
There would still need to be a set of tags that are recognized by browsers as reserved words just like programming languages have reserved words. You can’t have a function in JavaScript called “floor” for example.
With custom tags groups could come up with their own best practices for semantics just like Google dictated SEO practices. It would be a hell of a lot easier then to implement guidelines for things like <nav>,<article>, and <section>
I don’t think a lot of designers and developers treat <div> tags as table cells but more as a grouping of content within a page, which is how it should be used for styling and DOM traversal.
Well, often I see, that a “dl-dd-dt” group is treated as a set of blocks, where the whole structure means “header”, “dd” stands for “logo”, “dt” is for “item of menu list”. I consider this to be quite semantic. It depicts just the same as a dictionary section.
(Maybe I confused the order of tags, but you got the point I’m making)
[…] Death To The Div » CSS/HTML, Coding, Rant » Russell Heimlichrussellheimlich.com […]
You could always use ‘s 😀
Yes I sure could always use a 🙂
It would be really easy to write some sort of conversion script. That way you can write some XML like and it would convert any non-HTML tags to
Also, a tip for figuring out where divs begin and end. Use HTML comments.
There is a whole technology for that called XSLT allowing you to transform XML into anything you want. I suppose this sounds a lot like XML but it’s just a refinement of the HTML language we have all known and loved.
But none of it is as easy as writing plain old HTML – I think that’s the point of this suggestion.
did you really just say “boogers”?
The name just popped into my head and it just stuck.
I’m not a taleban on div usage, but they are better than old font tags 🙂 Html 5 if successful will add a lot of semantic to the text content and this can be useful for automatic treatment of data by search engines, aggregators…
I can’t believe HTML still doesn’t have this capability. This should have been done a decade ago. What the hell takes so long for HTML to evolve? I do nothing but Actionscript development now which is fortunate because if I had to do HTML/Javascript I’d probably shoot myself. You guys have my sympathies.
Lol! What’s funny is that I left actionscript because html/css/js was just that much better for prototyping. Nothing beats the ease of html/css/js for quick progmatic templating and display.
This needs to happen. Webpages like Gmail are all but unreadable because of the number of divs, all happily nested. It’ll only get worse as webpages get more complex.
Great idea.
To avoid future tag collisions, perhaps use a star to identify custom tags like:
[*mytag] content [/mytag]
(Replace squared brackets for angled)
Just an idea for HTML6
HTML6… that should be ready to go by around 2046
I couldn’t agree more. I tried doing this when I first started using jQuery and was bitterly disappointed. I think it’s fair to let browsers steal names… It’s a programmer’s job to make sure to avoid using reserved words.
Well, you can write code like this:
<container style=”display:block; background-color:blue; width:500px;”>
<article style=”display:block; background-color:red; width:100px;”>
hello
</article>
</container>
hello
Firefox and Chrome render it the way you want, IE7&8 ignores the tags and only displays hello.
Yup, that is part of the problem. Browsers should handle any tag they don’t know about just like a div.
you can write code like that, but you don’t want to wade through endless div-itis crap? Inline styling is just as bad as div-itis and the people that style inline should be slapped. As well as some of the bickering twits working on HTML 5. All of this should have been done years ago.
Don’t forget, there are more than just IE, Firefox, Chrome and Safari. e.g.: Opera, text-based browsers like Lynx, Konqueror, OS’s like Linux, etc. So just because 90% of the world uses a PC/Mac doesn’t mean you should be shutting out the other 10%.
I for one, would like to be able to name the tag myself, but then you run into the problem of what if you take over a job or a site and someone else has named their tags and named them in some sort of ridiculous manner?
Naming conventions are needed, but the names should be appropriate for the section, like header and footer, article and section.
There also should be a way for developers to name their own tags. Oh, wait, there already is. There is also a way to avoid “div-itis” and it’s by using span tags and markup that actually makes sense. Look at code from around the web on corporate website and tell me how many div’s you can get rid of by using heading tags and lists for navigation… tell me how many of those sites are using lists for navigation but have that nav wrapped in 4 or 5 div tags that are needless?
It’s called “common sense” and it’s a traits a lot of web designers and developers lack. It’s also a trait that a lot of companies need to look into when they hire a designer/developer for said company.
Todd I can’t tell if you’re for name-your-own tags or not.
“I for one, would like to be able to name the tag myself, but then you run into the problem of what if you take over a job or a site and someone else has named their tags and named them in some sort of ridiculous manner?”
This is true today with Classes and IDs.
@Todd: The example I gave was simple: It showed using css to style elements. Forgive me for not taking the time to create a css class and using that instead. Bite your tongue for a second, and look at what the example is trying to show instead of “slapping” someone for using Arial font or blue background.
In the perfect world, we would just have a small core with pluggable markup that implements standardized, public and versioned semantic contracts (micro-formats). The first thing the parser would do is apply transformations on the markup according to the capabilities (browser plugins).
I currently abuse the DIV class name to find the elements marked “i18n” that I then do on-the-fly internationalization for. It’s super easy, at load time (or when use select from a drop-down) JQuery consumes a REST webservice that maps the element ID and locale to a localized string. So I wonder if that can be taken a step further. Not sure XML is the way to go though, there are less verbose hierarchical markup formats available.
Yea XML is bloat city compared to JSON. I heard this guy theorizing about how one day we would be constructing our entire sites dynamically using things like JSON and AJAX (minus the XML part ofcourse). It sounds crazy but when you think about it can actually make a lot of sense (obviously i’m not describing it as well as he did.)
@Russel: I wasn’t sure if you were being sarcastic at first :). I think everything will move more towards json/ajax/canvas. It just makes sense.
But all of that will wreak hell with the text based browsers. Someone needs to start delving in to text based browsers to give them a certain amount or level of js and css in order to give them at least the base dom replacement and display semantics (mainly text line breaks etc) that we take for granted in the GUI world.
I haven’t messed with a text browser in a few years. Does anyone know if there has been work on this front?
lets move on…
[…] random assortment of technical links we found and liked. Russel Heimlich waves the HTML5 flag with Death to the DIVPew Internet did an interesting survey about The Internet and Civic EngagementFont Squirrel has a […]
Well, if the browsers can implement XML rendering with CSS and Javascript, then we can free to create whatever tag we want.
I coul end up comming accross a page like this:
header
navigation
sidebar
main body
footer
this every unknown tag could be bad for maintainability, some developers will start making up esoteric tag names and we’ll all be worse off..
We wouldn’t be worse off because the browser would treat it like a meaningless DIV tag. It’s just like being able to give any element an ID that is whatever you want. Same idea.
Meaningless is trying to chase down the ids that make just as little sense as people claim the tag names will.
Obviously there is a tag name collision problem here, which would make the web fragile and none of us want that.
What’s wrong with using XHTML with namespaces, precisely?
Then you can write
and so on to your heart’s content.
Yea even something like that would be a good start. Then we would just need to make writing XML Namespaces easy for mere mortals and not content mavens.
The article fails to take into account *why* people use an abundance of div tags for everything. True, there’s some who will just use it like table cells, but in many cases an extra assortment of divs is required just to display a three column layout!
I dislike it too – but the reason is simple. CSS does not have the chops to create easy layouts out of minimal elements – sure, work is being done for CSS3 but we’re still not there yet. Floats were designed to position images and not full pages.
The quicker we see new layout modules (http://www.w3.org/TR/2009/WD-css3-layout-20090402/) in wide use, the quicker we’ll start to see leaner pages that make use of less divisions. Would be nice to get a three column layout of a heading tag and three paragraphs. 🙂
I’ve become used to the way of laying out pages with CSS2. Those new layout modules are a bit tough to wrap my head around and I’m not sure I see much of a benefit. DIVs will be with us for a long, long time. It’s just a shame to see all of this effort to get a few new elements instead of going all the way and allowing name-your-own tags.
great reading! thanks for sharing your thoughts 🙂
but I think the problem is not the DIV (nor the SPAN). A lot of (web) developers I talk to don’t understand the underlying concepts of html markup and how it works (and many of them do not even care because the DIV is just so easy to use).
when you start giving people “native tag names” it does not automatically lead to better markup or better understanding of the content these “native” elements hold. it could even get worse not only because of the imminent cultural differences (the same thing can have a different meaning in other countries/cultures) but also because of the lack of standardization/generalization. this could ultimately lead to a “Babylonian state” where nobody cannot understand anybody.
and what if lazy developers start creating elements like MYCONTAINER1, MYCONTAINER2?
I am also not a big fan of HTML5 with all the new “container” elements like NAV, ARTICLE etc. I am more comfortable with the ROLE attribute and WAI ARIA.
but I think that’s personal taste 🙂
There are always going to be people who don’t care about semantic meaning, or using tags properly as long as they get their task done fast. They exist now with classes and IDs (id=”myelement” class=”greenComicSansBold”, Bleh!) I’m just proposing a way to simplify things. Of course there will be trouble and confusionat first, but after that we can easily come up with more flexible best practices.
For a more specialized webapplication we used XML-namespaces that works with getElementsByTagName (); in IE. You have to find the right combination though, so it’s not a lot of find and will probably break eventually. 🙁
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?
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.
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!
“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
We’re almost there. If we can just get IE to hop on board…
Do you think its the death of the div, but why there are still many sites still using it?
I think Divs should die they’re nowhere near their deathbed as of now.
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.
http://www.russellheimlich.com.....o-the-div/
This was very helpful – I will surely recommend this to my friends.
Great post guys.
[…] 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 […]
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.
hi this is a very intresting website and collection of information and data on thoses sharing my sirname.
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.
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.
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
Great article guys, was an interesting read.