Now, if you're not using Internet Explorer
5+, Opera 5+, or a browser based on Mozilla, such as NS6+, then
those two pages (table
layout and CSS
layout) probably look quite different. In fact, although the
table layout page will look nearly identical in all browsers dating
back to Netscape 1.1, only the most recent browsers (such as those
listed in this paragraph) will properly display the CSS layout.
According to recent browser usage stats, those most recent browsers
make up of roughly 75% of the browsing audience.
Make no mistake: pages laid out with CSS
will NOT look the same in newer and older browsers. Beginning with
5th generation browsers (including the most excellent IE5/Mac,
Netscape 6 on all platforms, and Opera 5) CSS support for layout
reached an acceptable level. Nearly identical CSS layouts are
possible in this browser set. Older browsers, including the
tenacious NS4, and even the ahead-of-its-time IE4, are lacking in
their support of even the CSS1 recommendation from 1996.
Consequently, CSS layout is for the most part impossible in these
browsers, with the exception of non-liquid, pixel-specific layouts
such as those used in games.
But don't despair. As you will see, CSS
pages are degradable, and CSS will create a useable page for any and
all browsers. CSS layout will be used only by those browsers which
support those features, but those using older browsers will still be
able to see your content. What you give up in absolute control over
layout in every browser you gain back in increased accessibility and
more useful documents.
But given that roughly 25% of your site
visitors will not be able to see your layout (although everyone will
have access to your content), the natural question is "Why use CSS
Why Use CSS for Layout
I've already mentioned a few of the negatives of CSS
layout and hinted at some of the benefits. Let's take a look in more
detail at the pros and cons of CSS layout. In the end, I think
you'll agree with me that the benefits far outweigh the
Benefits of CSS layout
CSS allows you to separate the structure and
presentation of documents. The separation of structure and
presentation (often incorrectly referred to as the separation of
style and content) is a principle that governs (or should govern)
all markup languages, such as HTML. HTML is intended to structurally
organize the content of a document so that it's clear what the
conceptual relationship is between various portions of a document.
The markup language is NOT intended to define the display of the
document, although display and structure are often tightly
A Primer for Accessible Web Pages -- A look at the history of Section 508, which enforces accessibility for government web sites, followed by a discussion about how to prepare pages for those who cannot effectively use a graphical user interface.
Modifying Styles -- Although browser support for Cascading Style Sheets has improved, modifying styles on the fly can still be painful at best. Fortunately, Steve Champeon provides a script to read and change an element's styles--regardless of where they were originally defined.
DOCTYPE Explained -- The DOCTYPE element, in the head of your document, tells the browser what kind of HTML is used to describe the file. The better you match the DOCTYPE to your code, the more accurate your work will be rendered. Here's an introduction.
As web developers we have been trained to
see an <h1> tag as a way to make something bold
and large, not as a way of marking it as a section header. The
introduction of physical tags, such as <b>,
<i>, <font> and the abominable
<blink>, all of which specify display qualities
of document elements and not structural qualities, have only made
things more confusing for the developer. And this confusion is
unfortunately reinforced by the behavior of web browsers, which
apply styles to section headers and indeed make them large and bold.
But it is wrong to think that the markup is what specified the
style; in fact, the browser decides how to display a section header
according to internal logic given to it by its programmers. Had they
wanted, they might have specified that section headers be displayed
italicized, or with an underline. And that is where CSS comes in to
the picture. CSS allows you to override the browser's plans for
displaying any particular page element or group of elements.
The separation of structure and presentation results in the following benefits:
A semantic web: You may have heard of the semantic
web before; it is a vision for the future of the internet where
the millions and millions and documents available on the web are
well-structured documents with markup that accurately describes
their contents. In such a world, documents become much more
accessible and understandable to computers, which makes it
possible for computers to better act as a person's agent. For
instance, search engines would function more effectively, as
document indexers could take advantage of the markup of documents
to organize results. More exciting possibilities include
programmable bots which could scour the reaches of the web for the
best price on buffalo milk mozzarella or for the latest interview
with Britney Spears. If a document's markup describes the content,
then computers are better able to understand the content.
Ease of redesign: Once we have removed layout
instructions from the markup of our documents, redesign becomes a
relatively simple task. Instead of cutting and pasting content out
of tables, we simply write a new style sheet and apply it to our
document. A whole site can be given a new look in seconds. Many
sites already take advantage of this benefit of CSS layout,
enabling site visitors to pick a "skin" for the site and applying
different style sheets on the fly.
Degradable code: Some people feel that if you want
cross-browser, backwards-compatible code, you have to use tables.
Of course such thinking is a result of a fundamental
misunderstanding of HTML, which as I've said is intended to carry
structural information about a document. The most
backwards-compatible (and forwards-compatible) code is that which
is free from all bad HTML, such as physical tags and tables used
for layout. These tags are nothing more than a wrench in the
works, keeping more primitive devices such as text-only browsers
and phone-based web interfaces from getting what they came for:
Yes, by eschewing tables for layout and
ridding your HTML of physical tags your page may not look as nice in
NN4, but your content will be 100% accessible. Muck your pages up
with tables and your site may look better in NN4, but you also
interfere with other less capable browsers and internet devices from
retrieving your content. In nearly all situations, I'll choose 100%
accessibility. In some cases, of course, the design must win. Some
content is only intended to be seen by 4+ browser users, and you
could justify the use of table-based layout in such situations. In
other situations it is worth the investment of time and money to
create server-side solutions to provide content to devices with
different capabilities. Doing so, you can feed table-based layouts
to 4+ browsers, and feed clean and simple markup to older and
less-capable devices, but most of us only want to maintain a single
document, not a server application. Valid structural markup and CSS
provide us with the opportunity to offer a single document that
works in all Internet devices and has a complex page layout in the
5+ browser set.