Tables or Div?
Div Problems
The <div> tag can be very useful, but it's important to keep in mind what div stands for: division. The div tag is supposed to divide the page into parts, and it does this extremely well. See for instance the right column, or the lower left hand tech data box, of the index page to see how the div element can be very effectively used.
Of course, you can go all the way, like we did, but we don't recommend that, for one main reason:
Div tags only expand to fill their container blocks horizontally, unless they are being sized against another absolutely sized element. This means that if you allowed div tags to go to their default behavior, they would only go down as far as their content made them go down. In other words, if you have two div elements next to each other, one with 200 pixels of text in it, the other with 350 pixels of text, the one with more text will go further down the page. This can be a pain, since often you want the page to act as one unified and connected whole.
On the first version of this site, we got around that problem by adding this to our CSS: body, html {width:100%; height: 100%;}, which then makes the body and html elements the primary containers against which all the divs on the page are sized, the 100% refers to the browser window viewing area, not the document height, there is basically no way to set two div elements to adjust in height to each other once they are off the page unless you set absolute heights on them both. At least that's what we thought before finding out that this isn't completely true.
However, since that required the use of iframes, which we've since abandonned, the redesign of the site required a new method. As you can see, the 3 columns do in fact line up correctly, no matter how much content there is in any one of them. How did we do achieve the true 3 column so called 'holy grail' of CSS / P div site construction? Study the code and see if you can figure it out. It would have been simple if MSIE had correctly supported the methods we use, but of course it doesn't.
This method does not require the ugly hacks most others you'll see out there do, like using background images to make fake columns and borders. This site is fully liquid horizontally, the columns are true columns, no images are used to create them or the borders. Is this easy to do, or even practical to do for most sites? No. For most users, a table would be a lot easier, and would be a lot more stable.
Tables of course default to the behavior of all cells adjusting to the content of the other cells, (acting like a unified connected whole, that is), and can only be stopped from doing it by applying special styles to them. Likewise, div tags can only be made to mimic this behavior by applying special styles to them, in this case by setting their height attribute to equal some fixed value, no matter how much content the div cell has. Some browsers will expand the div cell downwards to allow for more content, others will, correctly, simply cut it off when this height has been declared explicitly, making for very bizarre and ugly errors.
The CSS attribute: overflow:auto; was supposed to handle this but is as of version 1.6 Mozilla, 7 Opera, and 125 Safari, not correctly supported, in that you have to move the resultant overflow scroll bar on the element with the mouse, which is very inconvenient. Only Internet Explorer 5.5 windows correctly implement this feature, although Mozilla Firebird 0.7 - Firefox 0.9 have this feature working perfectly, the only browsers except IE 5.5 Windows to do so. Internet Explorer 6 has a new bug that makes the scrolling break if there is an empty space in the scrolling section, something with no text that is. Opera 7.5 finally got mouseover wheel scrolling working, but only AFTER the user physically clicks in the scrolling div, in other words, totally useless. Opera 7 pre 7.5 required manual scrolling. Opera 6 offered no support at all for this feature.
The upshot of this is that if you want adjacent cells to size vertically relative to each other, and not only their content, then these cells must be table cells.
Div tags as frames:
We have tried using the CSS overflow:auto; property on div elements to see if we could make them function like frames or iframes. Unfortunately, the results were so unreliable in a multibrowser environment that we abandoned the effort. In Mozilla/Netscape, it sort of worked, but not quite (would not scroll with wheelmouse even if you clicked in the display area. In Internet Explorer >= 5.0 for Windows it worked perfectly, exactly like you think it should. In Opera 6 it was not supported at all, and is partially supported in Opera 7. It does not scroll correctly in Safari either as of version 125 as far as we know.
Unless your pages will only be used in Windows Internet Explorer version 5 or greater, this technique cannot yet be used, except for more experimental sites like this on (make the page have a very small height on the index page, for example, and you can see overflow:auto on the left and right bars. This is unfortunately an intriguing method, but one that is not yet ready for the mass market, and one that would solve almost all the problems with frames and iframes. As is usually the case with the best CSS 2 technologies (see also the 'position:fixed' property), this is not correctly or consistently implemented in all the browsers.
Good Div things:
Div tags serve very well for the following purposes:
- Acting as container elements for sub–elements, like paragraphs.
- To position an element, or to place a border around an element.
- To center an element. Because Internet Explorer 5.x and 6 (when in quirks, not standards, mode, which means the document does not have the correct DTD and HTML version information) do not recognize margin:auto;, you have create two styles to center an object inside a container. First, the container must be given this: .container {text-align:center;}, to support IE's non-standards way of centering objects, then you have to give the object itself this .theobject {margin:auto;}, which will balance the right and left margins automatically, but not, note, the top and bottom ones.
- Perhaps most important, to create vertically stacked page sections, each containing a certain grouping of content. This is probably what div is actually intended to do, since it does this without any CSS styling at all. Each section can contain several paragraphs, for instance, or a navigation bar, like the one on top and on the bottom of this section, which is a div element styled to have top and bottom double line borders.
The div tag is basically the jack of all trades of tags, having the ability to function as anything from a table cell, a paragraph, to the primary container of the whole page.
Div tags really position well, this is how we made this site, the floating semi–opaque purple bar with the 'home', 'contact', and 'about' links in it is a floating div element that has been positioned over the other positioned div elements of the page. Each <a> link is positioned by means of a positioned div container element.
Our particular favorite for div elements is to use them as containers for a block of h and p tags. Using CSS properties such as margin, padding, and border attributes, a very nice looking container can be created with a minimum of work.
Our Tentative Conclusion:
After our experiment with techpatterns.com, we decided that these kinds of advanced techniques were simply not viable for commercial use, at least to the degree found here, although they can be used in more basic ways very effectively and still be safe for almost all current browsers.
In our opinion, the best solution, if vertical structuring of the site web page is desired, is to combine the two techniques: make the basic structure a simple table, then create all sub–structures with the div elements. That results in very clean, stable code, which will run very well in all browsers except the dreaded Netscape 4.x series, which have mediocre div support. However, netscape 4 support can be no longer be expected or required, except in certain very unusual circumstances.
There is also a significant philosophical issue involved with using CSS to position div elements. The whole point of the creation of CSS was to get all formatting off of the webpage. Not to create the actual structure of the webpage, which is what CSS 2 is moving towards. Of course, the HTML on the page will always have a physical layout, a flow of information, so where each element of that flow will in that sense always be determined by the person creating the code. But it does seem like CSS 2 has gone a bit overboard, especially when it comes to positioning.
The fact remains, however, that any page created with more advanced CSS technologies will not display correctly in netscape 4 browsers, which is unfortunate, but that horrible product has held the internet hostage for long enough, and can now more or less be ignored, unless you are working on a massive website that must support all users.