Introduction to CSS Layout
Pages: 1, 2, 3, 4

Problems with CSS layout

To fully understand CSS layout, you must not only be aware of it's benefits, but you must also be ready for some problems it presents. Most of these problems stem out from CSS's immaturity. Yes, the recommendation itself has been around for a while, but CSS layouts are only recently possible, and even more recently taken seriously by developers. Expect this immaturity to result in problems, such as:

• Layout limitations: The fact is that CSS layout will not currently allow you to do everything you can do with tables. This can be a real frustration, and has stopped many people from exploring what CSS can do. (I'll show you in this article that CSS can do quite a bit.)

• Slight differences in browser display: CSS is difficult for browser makers to implement, and the W3C recommendations can be vague and confusing. So you can expect even the most recent browsers to behave differently when dealing with some aspects of CSS layout. Keep your layout simple enough and you will likely get a nearly identical display in Opera 5+, NS6, and IE5+. But as your layout increases in complexity, the odds that different browsers will render pages differently also increases.

• Difficulty in switching from tables to CSS: For designers and developers accustomed to wrangling tables, using CSS for layout can be a confusing change. There is a "table mentality" that we developers have taken on over the years, and we are in large part unaware that it exists. Some take offense when this is pointed out, complaining instead that CSS is just difficult and non-intuitive. But if you were accustomed to driving a car with a steering wheel and you were then asked to head out on the freeway in a car steered with foot pedals, you certainly wouldn't be offended at the suggestion you had a "steering wheel mentality." The fact is, we are generally comfortable with tables. CSS layout is different, but we must not confuse differences with increased complexity.

So then, with all these problems, why use CSS? You'll have to make this decision yourself. Many people I know use CSS layouts for personal web projects, but still resort to tables when working on commercial sites. The time is coming when CSS will be suitable and preferred for all site layout, but many reasonably argue that the time has not yet arrived.

I use CSS because I believe in the fundamental principle of the separation of structure and presentation, and I am willing to put up with the problems CSS presents as I look forward to a time when CSS is as robust and simple to implement as tables are today. That time will come, and the web will be a better place for it.

Example: Re-coding the Internet Developer Home Page

To make things interesting, I took the Apple Internet Developer home page, which makes extensive use of tables, and I re-coded it using CSS for all layout. I've made a copy of the home page as it existed when I started this article, and I've turned on all table borders so you can see what we're working with: the Apple Internet Developer home page with table borders.

Now, If you're using IE5+ or NS6+, you should see virtually the same layout here: The Apple Internet Developer home page with only CSS. Opera 5+ users should see a very similar page, but with a few display quirks.

Now that I've shown you the fruits of my labor, take a closer look at the techniques used. Start at the top of the page, where there is a 600px wide graphical image bar centered in the browser window.

using a table this is accomplished something like so:

<center>
  <table width="600"> ... </table>
</center>

The complete markup can be seen in the file top_nav_table.html.

Using CSS I got the same results by using a DIV instead of a table element, and setting the DIV's margin attribute to the value auto, like so:

<style type="text/css">
#top_nav {
  margin:auto;
  width:600px;
  } 
</style>

<div id="top_nav"> ... </div>

Sadly, this is where I ran into the first browser discrepancy. IE5.x does not properly implement the auto keyword, and so the DIV will not be centered in that browser. Happily, there is a simple workaround: by setting the text-align attribute of the DIV's parent element (in this case, the body element), to center, I ensure that IE5.x will center the DIV:

body {
  text-align:center;
  }

Those familiar with CSS may know that this is a mis-implementation of the text-align attribute. But in this case, it does provide a useful workaround.

Now take a look at all the style rules used in creating the top navigation bar using CSS (the complete markup can be seen in the file top_nav_css.html):

#top_nav {
  margin:auto;
  width:600px;
  height:32px;
  text-align:left;
  }

I've already talked about the margin and width attributes of the #top_nav rule, the height attribute is self-explanatory. The text-align:left attribute is necessary because the text-align:center on the body style rule will be inherited if this is not given. Actually, you would think both of these latter attributes would be unnecessary for this DIV, but removing them causes IE5 Mac to incorrectly display the DIV. Better to leave them in.

#top_nav a {
  display:block;
  float:left;
  }

This rule causes all the links in the top_nav DIV to be treated as block elements instead of using the default inline display value for anchor elements. You can then float each of these elements left, which is essentially the same as using the align attribute of a block element or an IMG. This would normally not be necessary, but notice that one part of the navigation bar is not an image at all: it is a form. Once I floated all the images left, which makes them align horizontally next to one another, I inserted a form in this series of images (a form with the id "MidSearch"), and applied the following style to it:

#MidSearch {
  float:left;
  margin:0px;
  background-image:url("img/navbg.gif");
  height:32px;
  }

Notice that I used a background image for the form, which places an image behind the form's text element and makes it blend in nicely with the images in the navigation bar. The following rule defines the display of the form's input element:

#MidSearch input {
  width:100px;
  height:18px;
  margin-top:4px;
  }

And there you have it. I've replaced a double nested table structure with a simple series of links wrapped around images and a simple form. All the layout information has been moved into the style sheet. If you haven't already done it, now is the time to compare the markup code: using tables vs. using CSS

Next, take a look at the top middle section of the page, starting below the top navigation bar and ending at the first gray horizontal bar:

I won't spend any time on this code for this section because it uses the same CSS techniques as the top navigation bar.