Point/Counterpoint: The Wrapper Div
Point: The wrapper div (a generic div element placed just inside the body, encasing all other elements) can be an effective way of producing a sub-body element of which you can have full control.
Counterpoint: The wrapper div has no semantic meaning whatsoever.
Point
The wrapper div (a generic div element placed just inside the body, encasing all other elements) can be an effective way of producing a sub-body element of which you can have full control. It allows you to cut down the size of your CSS file size by creating an additional parent element to specify characteristics such as width, font-size, background-color, etc.
Sure, the wrapper div itself may not have much semantic meaning, but its benefits far outweigh that drawback. I can save the user a few K of bandwidth, while making my own development process a little easier. CSS bugs and browser differences already make us include certain non-semantic elements or hacks in our XHTML and CSS that we wouldn’t need if things were implemented properly. The wrapper div is a minimalist approach to dealing with such differences, and it does so gracefully and easily.
Counterpoint
The wrapper div has no semantic meaning whatsoever. So you need an element that wraps around all your content for styling purposes? That’s what the body and html elements are for! Sure, they may be buggy in some browsers, but creating non-semantic elements to make up for these bugs is just plain laziness.
I could argue that if you needed this additional element that <table><tr><td> (content) </td></tr></table> takes up just a little more bandwidth than <div id="wrapper"> (content) </div>, provides you with much more flexibility, and is just as semantically (un)sound. Does that make it right? Nope. The wrapper div id just another element on the slippery-slope to bloated, non-semantic markup.
Post and Author Info.
Published March 14, 2005 by:
Commenting is currently off for this post.
So far there are 19 comments.
I always style the body and html tags and I seem to get away with it on IE6, Firefox and friends, Opera, and Safari, which is good enough for me, at this point.
On the other hand, adding divs as style hooks will be unavoidable with CSS3 also. You just need blocks of content, and divs do that. If you need a block spanning the entire page just because some browsers you want to support need it, then you ought to do it, since it’s a very small violation from the “orthodoxy” of semantic structuring of pages.
March 14th, 2005
I know I’m probably going to have to don my asbestos suit for saying this, but if it works, it can’t be that terrible a thing. I’m not going to start defending the use of tables for non-tabular data or anything, but I can’t see why the purists get in a tizzy about adding a tag to allow greater flexibility in styling content.
Thinking about it a little deeper, I’d probably argue for this. Take the theme on this site, for example. The central column of content (div id=”wrapper”) is just one more element of a valid document. It is, IMHO, no different from a paragraph tag. It holds data, and that data may or may not include other valid tags.
March 14th, 2005
Would it make sense for CSS3 to include some kind of attribute we could use on the div tag to expressly tell machines reading the page that this div is non-semantic—just a style hook?
<div id="wrapper" semantic="no">Really not sure myself if that would accomplish anything useful.
March 14th, 2005
Technically that’d be an XHTML attribute, of course, not in the CSS spec… ^^
March 14th, 2005
Creating a wrapper div inside your “main structural DIV” maybe less semantic, but just because it allows you to escape the Box model Hack in your css, i think it is worthy. The day that CSS will be implemented properly on all browsers, then i agree that we should avoid bloating our code with unecessary elements. But since the sun isn’t rising yet for that shiny day, i think it doesn’t hurt to help yourself with some generic DIV. Plus, when you have complex layout with multiple background images, it gives you one more layer to work with.
March 14th, 2005
A DIVISION is semantically a wrapper element, no? You’re not wrapping something your creative a division.
Naturally, many things can be in a division including other divisions. A division is “a generic block-level container”.
At the same time, yes, going crazy with divisions is, well, fugly.
But it’s your code. Since divisions have no presentational connotation I wouldn’t equate them to tables—which have presentational meaning. So long as you don’t mind having fugly code it’s your call.
So, I say, there’s nothing wrong with using a division as a wrapper since that is what a division is for. However, as with everything in life, moderation is key.
March 14th, 2005
Say you have a bunch of elements you want to group together, how would you do it? Say also, you may need to move the group as a unit, how would you do it?
I use a div for that. Even if it isn’t “semantically correct”, I can live with the trade-off.
March 14th, 2005
Using an unnecessary div element as a styling hook is certainly not the same as using an unnecessary table element as an styling hook.
The div element type has no semantics beyond “this is a chunk of the document”. The table element type does. That’s why it’s wrong to use extraneous table elements as styling hooks but acceptable to use extraneous div elements as styling hooks.
I agree with Gabriel though, styling the html and body elements doesn’t usually cause any problems for me. Styling the head element is usually a bit more buggy though.
March 14th, 2005
Sorry. I wasn’t saying that divs and tables are the same kettle of fish at all. I was just drawing a small comparision between using them inappropriately. (Just for clarification, my position is that a wrapper div is not innappropriate). I started my comment by going off on one about parent nodes in XML, confused myself and deleted that paragraph. If I could have written it in a way that made sense to me, I’d have left it in.
March 14th, 2005
I think the counterpoint you have up there is rather weak.
The wrapper div isn’t always needed, but in most cases, when an actual “design” is required it’s the best way to handle IE. (Let’s face it, all the other browsers follow the spec with regards to the body tag and margin:auto;)
Perhaps someone should include this in a suggestion list to Chris Wilson? :-)
March 14th, 2005
I think the real challenge to this question is to test to see if you can go without a wrapper div, or using divs period. For fun, I did. I think a lot of times, we sometimes forget that many of the basic elements we use (h3, p, etc.) are block-level by default. If we can take advantage of their intrinsic behavior, then we can maybe shed our dependence on ‘generic’ div elements.
Of course, this is a visual medium (for graphics-enabled Web broswers). For this, I would say that the div wrapper is beneficial to serving extra content (images) that makes sense semantically for the capable user agents that can render them. If you are trying to use a div to govern areas of structure (wrapper), consider whether lists or headings/p tags might not be more appropriate. The place that seems to really require a div wrapper the most to hold design together would have to be forms, which could be another point/counterpoint altogether…
March 15th, 2005
Sorry, broken link to example above:
Here it is
March 15th, 2005
Remember that the form tag itself can be styled and have width applied so it is a pretty decent wrapper itself.
March 17th, 2005
True,
But inputs need a block-level wrapper around themselves to be valid (and surprisingly not just ‘form’). In this instance, I have found divs to be a perfectly acceptable alternative to just wrapping them in p tags.
And try experimenting with forms that are floated in more complex layouts. Non-div wrapped forms will give display inconsistencies across browsers that make you go crazy. When wrapped in a div (and carrying over the style of the form to the div) these inconsistencies vanish. I think it is really more of a browser issue with forms.
March 17th, 2005
Jason
- try “fieldset” -that’s how you should wrap inputs, unless lists make more sense for your content… :)March 17th, 2005
I use both fieldset and I like the idea of wrapping the input inside a label tag. I’ve also experimented with display block on the label and floating them left when they need to share a line with other inputs…
March 18th, 2005
Beware of Netscape. An earlier version (6.2?) made label elements disappear when they were floated.
March 18th, 2005
I like the idea of using wrappers for extra styling and control. But It can become overwhelming there are several nested inside of each other. I need the child wrappers to inherit the positioning of the parent, but I also need them to be a parent to the div’s within. For example:
bodydiv id=”container”-a class=”skiplink” href=”#startcontent”Skip over navigation/a-div id=”banner”-banner image and content here/div-div id=”navwrapper”div id=”nav”-nice ul list here/div-formdiv id=”search”-search code/div-/form/divdiv id=”wrapper”div id=”sidebar”contentdiv id=”news”-/div-/divdiv id=”contentwrapper”div id=”content”-content -/div-div id=”subwrapper”>div id=”sbdc”content-/div-div id=”success”content-/div-/div/div/divdiv id=”footer”-content-/div-/div/bodyI am having a hard time with the children of “subrapper” to play nice. I need subwrapper to inherit the positioning of conentwrapper, and at the same time “sbdc” and “success” to play nicely.
I would post my css but I noticed code is messing up the page.
Any solutions?
March 30th, 2005
To me, the DIV element (along with SPAN) in and of itself implies no semantic meaning. If there was a semantic element for the group of elements we were wrapping, we’d use it. But there isn’t. That’s what DIV is for. To group a chunk of content that isn’t otherwise “tagable” by the elements that exist. The fact that it has no semantic meaning is irrelevant, in my opinion.
Of course, if you can get by without it (by styling BODY, or other elements), then by all means do so. But I see nothing wrong with using a “wrapper” DIV.
April 25th, 2005