To use a fine art analogy, working with tables is like painting by numbers: you create a
skeleton layout and then fill in the gaps with the content of choice. And, like painting by
numbers, a lot of work is required to change the layout after it’s completed. Working with
CSS is more akin to sculpting with clay: you begin with something simple and then gradually
fashion your layout. Making changes, tweaks, and even additions at a later date is simpler,
and the whole process feels more organic.
Long-time web designers may feel intimidated by CSS because they don’t initially have the
skeleton layout of table borders to work with. In some ways, CSS sits at the extremes of
web technologies, being both very graphic and design-like (in its flexibility), but also quite
technical (in how it’s created). Tables tend to sit in the middle of these two extremes.
However, once you get the hang of CSS workflow, it soon becomes second nature. Now,
we’ll look at how to create a web page structure, and we’ll then recap the CSS box model.
Showing posts with label tables. Show all posts
Showing posts with label tables. Show all posts
Wednesday, September 29, 2010
Layout technology: Tables vs. CSS
Unless you’re the sort of person who favors very basic web pages, with most elements sitting
underneath each other, you’ll need to employ some kind of layout technology when designing your web pages. Historically, web designers tended to use tables for doing this,
combined with invisible GIFs (sometimes called spacers or shims) to stretch table cells to
the required size. In the early 2000s, CSS layouts gained a foothold, and now more and
more designers are moving toward CSS as a means of page layout.
With few exceptions, pretty much everything you can do with a table can be done faster,
better, and with a greater emphasis on accessibility when using CSS. With content and
design separated, it’s much easier to tweak or rework a website, because you’re editing an
external document that controls spacing and positioning, rather than messing around with
complex tables. We discuss one of CSS’s major benefits in this regard, how it encourages
logical element placement, in the next section. Tables should really be reserved for their
original purpose: formatting tabular data.
underneath each other, you’ll need to employ some kind of layout technology when designing your web pages. Historically, web designers tended to use tables for doing this,
combined with invisible GIFs (sometimes called spacers or shims) to stretch table cells to
the required size. In the early 2000s, CSS layouts gained a foothold, and now more and
more designers are moving toward CSS as a means of page layout.
With few exceptions, pretty much everything you can do with a table can be done faster,
better, and with a greater emphasis on accessibility when using CSS. With content and
design separated, it’s much easier to tweak or rework a website, because you’re editing an
external document that controls spacing and positioning, rather than messing around with
complex tables. We discuss one of CSS’s major benefits in this regard, how it encourages
logical element placement, in the next section. Tables should really be reserved for their
original purpose: formatting tabular data.
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
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
Styling a table by Css : Adding borders to tables
As mentioned earlier, it’s a good policy to avoid using the default HTML table border. It
looks ugly and old-fashioned, and it’s a far cry from a clean, flat, 1-pixel border. You might
think it’s a straightforward process to add CSS borders to a table—logically, it makes sense
to simply add a border property/value pair to a grouped selector that takes care of both
the table headers and table data cells.
th, td {
border: 1px solid #c9c9c9;
}
But this doesn’t work. As the screenshot to the right shows, this method
results in the correct single-pixel border around the edge of the table,
but creates double-thick borders everywhere else. This is because the
borders don’t collapse by default, meaning that the right-hand border of
one cell sits next to the left-hand border of an adjacent cell, and so on.
Designers have historically gotten around this by using a rule to define a style for the top
and left borders of the table, and another to define a style for the right and bottom
borders of table cells. However, there’s a perfectly good property that
deals with the double-border syndrome: border-collapse. When this
property, with a value of collapse, is applied to the table element via an
element selector, borders collapse to a single border wherever possible.
The other available border-collapse property value, which reverts
borders back to their “standard” state, is separate.
table {
border-collapse: collapse;
}
With this brief explanation of table borders completed, we’ll now move into exercise
mode and style the table.
looks ugly and old-fashioned, and it’s a far cry from a clean, flat, 1-pixel border. You might
think it’s a straightforward process to add CSS borders to a table—logically, it makes sense
to simply add a border property/value pair to a grouped selector that takes care of both
the table headers and table data cells.
th, td {
border: 1px solid #c9c9c9;
}
But this doesn’t work. As the screenshot to the right shows, this method
results in the correct single-pixel border around the edge of the table,
but creates double-thick borders everywhere else. This is because the
borders don’t collapse by default, meaning that the right-hand border of
one cell sits next to the left-hand border of an adjacent cell, and so on.
Designers have historically gotten around this by using a rule to define a style for the top
and left borders of the table, and another to define a style for the right and bottom
borders of table cells. However, there’s a perfectly good property that
deals with the double-border syndrome: border-collapse. When this
property, with a value of collapse, is applied to the table element via an
element selector, borders collapse to a single border wherever possible.
The other available border-collapse property value, which reverts
borders back to their “standard” state, is separate.
table {
border-collapse: collapse;
}
With this brief explanation of table borders completed, we’ll now move into exercise
mode and style the table.
Scope and headers of tables
Although table header cells provide a means of differentiating headers and other data, a
direct means of associating one with the other can be added via the use of various attributes.
For simple data tables, the scope attribute, added to table headers, provides an indication
of which data a heading refers to. For example, in the previous code block, the
table is oriented in columns—the headers are above their associated data. Therefore,
adding a scope attribute to the header cells, with a value of col, clearly defines this relationship—
and this is something that comes in handy for screen readers.
<th scope="col">Country</th><th scope="col">Capital city</th>
<td>France</td><td>Paris</td>
If the alignment of the table were changed, with the headers at the left, the row value
would instead be used.
<th scope="row">Country</th><td>France</td>
<th scope="row">Capital city</th><td>Paris</td>
Note that if a table header contains colspan or rowspan attributes—for example, if a
header, such as food, spanned two columns (thereby having the attribute/value pair
colspan="2") and had underneath two further headings, such as fruit and vegetables—
you could set scope="colgroup" in the table header start tag. The equivalent is true for
headers with a rowspan attribute, whereupon the scope value changes to rowgroup. In
such cases, you also need to use the colgroup/rowgroup elements.
These are positioned between the caption and thead of the table (see the following code,
and see the following section for an overview of the various structural elements of tables
combined).
<colgroup span="2">
<colgroup span="2">
<thead>
<tr>
<th scope="colgroup" colspan="2">Fruit</th>
<th scope="colgroup" colspan="2">Vegetable</th>
</tr>
<tr>
<th scope="col">Citrus</th>
<th scope="col">Berry</th>
<th scope="col">Root</th>
<th scope="col">Legume</th>
</tr>
</thead>
For more complex tables that have intricate structures, using many colspans or rowspans,
where it wouldn’t be immediately obvious where the relationship lies between a data
cell and a header, you can use id values and the headers element. Each table header cell
should be assigned a unique id value. Each table data cell that refers to one or more headers
requires a headers element. The value of the headers element is the id or ids that the
cell data refers to. Even for simpler data tables, this method can work well—see the following
code block for how our fruit and vegetables table snippet works with id and
headers.
<thead>
<tr>
<th id="fruit" colspan="2">Fruit</th>
<th id="vegetables" colspan="2">Vegetable</th>
</tr>
<tr>
<th id="citrus">Citrus</th>
<th id="berry" >Berry</th>
<th id="root" >Root</th>
<th id="legume" >Legume</th>
</tr>
</thead>
<tbody>
<tr>
<td headers="fruit citrus">Lemon</td>
<td headers="fruit berry">Blueberry</td>
<td headers="vegetable root">Potato</td>
<td headers="vegetable legume">Pea</td>
</tr>
</tbody>
Note that the code blocks in this section are here to highlight the attributes and elements
being discussed—they should not be seen as examples of complete tables.
direct means of associating one with the other can be added via the use of various attributes.
For simple data tables, the scope attribute, added to table headers, provides an indication
of which data a heading refers to. For example, in the previous code block, the
table is oriented in columns—the headers are above their associated data. Therefore,
adding a scope attribute to the header cells, with a value of col, clearly defines this relationship—
and this is something that comes in handy for screen readers.
<th scope="col">Country</th><th scope="col">Capital city</th>
<td>France</td><td>Paris</td>
If the alignment of the table were changed, with the headers at the left, the row value
would instead be used.
<th scope="row">Country</th><td>France</td>
<th scope="row">Capital city</th><td>Paris</td>
Note that if a table header contains colspan or rowspan attributes—for example, if a
header, such as food, spanned two columns (thereby having the attribute/value pair
colspan="2") and had underneath two further headings, such as fruit and vegetables—
you could set scope="colgroup" in the table header start tag. The equivalent is true for
headers with a rowspan attribute, whereupon the scope value changes to rowgroup. In
such cases, you also need to use the colgroup/rowgroup elements.
These are positioned between the caption and thead of the table (see the following code,
and see the following section for an overview of the various structural elements of tables
combined).
<colgroup span="2">
<colgroup span="2">
<thead>
<tr>
<th scope="colgroup" colspan="2">Fruit</th>
<th scope="colgroup" colspan="2">Vegetable</th>
</tr>
<tr>
<th scope="col">Citrus</th>
<th scope="col">Berry</th>
<th scope="col">Root</th>
<th scope="col">Legume</th>
</tr>
</thead>
For more complex tables that have intricate structures, using many colspans or rowspans,
where it wouldn’t be immediately obvious where the relationship lies between a data
cell and a header, you can use id values and the headers element. Each table header cell
should be assigned a unique id value. Each table data cell that refers to one or more headers
requires a headers element. The value of the headers element is the id or ids that the
cell data refers to. Even for simpler data tables, this method can work well—see the following
code block for how our fruit and vegetables table snippet works with id and
headers.
<thead>
<tr>
<th id="fruit" colspan="2">Fruit</th>
<th id="vegetables" colspan="2">Vegetable</th>
</tr>
<tr>
<th id="citrus">Citrus</th>
<th id="berry" >Berry</th>
<th id="root" >Root</th>
<th id="legume" >Legume</th>
</tr>
</thead>
<tbody>
<tr>
<td headers="fruit citrus">Lemon</td>
<td headers="fruit berry">Blueberry</td>
<td headers="vegetable root">Potato</td>
<td headers="vegetable legume">Pea</td>
</tr>
</tbody>
Note that the code blocks in this section are here to highlight the attributes and elements
being discussed—they should not be seen as examples of complete tables.
Creating accessible tables
Many web designers ignore all but the most basic elements when working with tables, and
in doing so they end up with output that causes problems for screen readers. By correctly
and carefully structuring and formatting a table, not only will users of screen readers benefit,
but you as a designer will also have far more control over its visual appearance.
Additionally, extendable browsers like Firefox can also enable you to use the table data
in other ways, including outside of the browser. For example, the TableTools plug-in
(https://addons.mozilla.org/en-US/firefox/addon/2637) enables sorting, filtering,
and exporting of tabular data from a web page. A properly formatted table will enhance
this, making the table even more useful. Adding a few extra elements and attributes to
your table is a win-win situation, and it’s surprising to note how few designers bother with
anything other than rows and cells in their tables
in doing so they end up with output that causes problems for screen readers. By correctly
and carefully structuring and formatting a table, not only will users of screen readers benefit,
but you as a designer will also have far more control over its visual appearance.
Additionally, extendable browsers like Firefox can also enable you to use the table data
in other ways, including outside of the browser. For example, the TableTools plug-in
(https://addons.mozilla.org/en-US/firefox/addon/2637) enables sorting, filtering,
and exporting of tabular data from a web page. A properly formatted table will enhance
this, making the table even more useful. Adding a few extra elements and attributes to
your table is a win-win situation, and it’s surprising to note how few designers bother with
anything other than rows and cells in their tables
Monday, September 27, 2010
How tables work
In this section, we’re going to look at how tables are structured, and some of the table
element’s attributes, which enable you to define the table’s dimensions and borders, along
with the spacing, padding, and alignment of its cells.
Tabular data works via a system of rows and columns, and HTML tables work in the same
way. The table element defines the beginning and end of a table. Within the table element
are table row elements (<tr></tr>), and nested within those are table cell elements
(<td></td>). The actual content is placed inside the td elements. Therefore, a simple table
with two rows containing two cells each is created like this:
<table>
<tr><td>Cell one</td><td>Cell two</td></tr>
<tr><td>Cell three</td><td>Cell four</td></tr>
</table>
element’s attributes, which enable you to define the table’s dimensions and borders, along
with the spacing, padding, and alignment of its cells.
Tabular data works via a system of rows and columns, and HTML tables work in the same
way. The table element defines the beginning and end of a table. Within the table element
are table row elements (<tr></tr>), and nested within those are table cell elements
(<td></td>). The actual content is placed inside the td elements. Therefore, a simple table
with two rows containing two cells each is created like this:
<table>
<tr><td>Cell one</td><td>Cell two</td></tr>
<tr><td>Cell three</td><td>Cell four</td></tr>
</table>
**Note :Always ensure that you include all end tags when working with tables. If you began
working with HTML in the mid-1990s, you may have learned that it’s OK to omit the
odd end tag from tables or table cells. However, not only does this result in invalid
XHTML, but some browsers won’t render tables accurately (or at all) when end tags
are omitted. Furthermore, there’s evidence to suggest some search engines can’t
properly spider pages that contain broken tables.
working with HTML in the mid-1990s, you may have learned that it’s OK to omit the
odd end tag from tables or table cells. However, not only does this result in invalid
XHTML, but some browsers won’t render tables accurately (or at all) when end tags
are omitted. Furthermore, there’s evidence to suggest some search engines can’t
properly spider pages that contain broken tables.
Subscribe to:
Posts (Atom)