Tips And Tricks For Tables layout in Css

This section is going to be brief, because you should avoid using tables for layout, or even
components of a layout (excepting tabular data, obviously). There are exceptions—for
instance, some web designers consider tables acceptable for laying out forms. However,
generally speaking, tables are less accessible than CSS, harder to maintain and update,
slow to render in browsers, and don’t print particularly well. More importantly, once you
know how to create CSS-based layouts, you’ll mostly find working with tables for layout
frustrating and clunky.
A common way of creating tabular layouts is to chop up a Photoshop layout and use
images to stretch table cells to the correct size. (As mentioned earlier, table cells expand
to the dimensions of their content.) Many designers then use a 1-pixel invisible GIF89
(often referred to as a spacer or shim) to force content into position or stretch table cells
to a certain size. Because the 1-pixel GIF is a tiny file that’s cached, it can be used hundreds
of times without impacting download times. However, spacer and table layout usage pretty
much destroys the idea of a semantic Web. Because so much of the layout is defined via
inline HTML, updating it requires amendments to every page on the site (which must also
be uploaded and tested in each case), rather than the simple editing and uploading of an
external CSS file.
It is possible to combine CSS and tables—something that’s usually referred to as a transitional
layout, although one might argue that the “transition” from tables to CSS layouts
should now be considered an historic event. Such layouts are usually created to ensure
layout-based backward compatibility with obsolete devices. This direction should only be
taken when the target audience is known to definitely include a significant number of
users of very obsolete browsers, and also when the layout is paramount to the working of
the site (rather than just the content). When working on such a layout, there are a few
golden rules:
Avoid nesting tables whenever possible: Although tables can be nested like any
other HTML element, doing so makes for a web page that is slow to render and
nightmarish to navigate for a screen reader. (Obviously, there are exceptions, such
as if you need to present a table of tabular data within your layout table.)
Structure the information on the page logically: When designers use tables (particularly
those exported from a graphics package), they have a tendency to think
solely about how the page looks rather than its underlying code. However, it’s
important to look at how the information appears in the HTML, because that’s how
a screen reader will see it. The content should still make sense with regard to its
flow and order even if the table is removed entirely. If it doesn’t, you need to
rework your table. (You can use Opera’s User mode to temporarily disable tables to
find out how your information is ordered without them. Chris Pederick’s Web
Developer toolbar for Firefox [www.chrispederick.com/work/web-developer/]
offers similar functionality via Miscellaneous ä Linearize Page.) Ensure that content
is immediately available; if it isn’t, provide a link that skips past extraneous content,
such as the masthead and navigation—otherwise, people using screen readers will
be driven bonkers. (See www.w3.org/TR/WAI-WEBCONTENT/ for more on web content
accessibility guidelines.)
Avoid deprecated attributes: For instance, there’s little point in setting the table’s
height to 100% when many web browsers ignore that rule (or need to be in quirks
mode to support it).
Use CSS whenever possible to position elements: To give an example—if you’re
working with a 3-cell table and want the middle cell’s content to begin 100 pixels
from the top of the cell, don’t use a spacer GIF. Instead, provide the cell with a class
or unique ID, and use CSS padding.As I keep hammering home, CSS is the way to go for high-quality, modern web page layouts,
and tables should be left for the purpose for which they were designed—formatting
data. The arguments that rumbled on for a few years after the 1990s came to a close—that
browsers didn’t support enough CSS to make CSS layouts possible, and that visual design
tools such as Dreamweaver couldn’t cope with CSS layouts—are now pretty much moot.
Even the previous major release of the worst offender (yes, I’m talking about Internet
Explorer 6) has more than adequate support for the vast majority of CSS layouts, and anything
shipping today is more than capable of dealing with CSS.
In my experience, the main reason designers avoid CSS involves their not knowing how to
work with it. Suitably, then, the next chapter deals with this very issue—showing how
to create page layout elements using CSS.
The last two of these rules are primarily concerned with ensuring that if you design for
legacy browsers, you don’t compromise your work for more modern efforts.
TABLES: HOW NATURE (AND THE W3C) INTENDED
255