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.

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:

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.