HANDOUT TITLE:



TABLES – TOOLS FOR ORGANIZING DATA

As the name suggests, tables are designed to present tabular data. This could include information displayed as a calendar of events or perhaps a spreadsheet. There are many different circumstances in which tables are a sensible choice - but laying out an entire web page is definitely not among them.

An example of a table

A table is the most sensible, tidy way to organize this kind of data. You can easily scan down a column, or along a row. The exact same effect can be achieved on a web page.

Why Tables Are Bad (but Only for Layout!)

The reason why web designers used to use tables for layout was quite simple. In the early days of web development, tables were the only way to achieve a layout that resembled a magazine or newspaper-like grid. Designers wanted to have a heading at the top of the page, a column on the left for navigation, a column in the middle for content and a third column on the right for more links. The problem was that using tables to achieve such effects was an ‘abuse of the markup’ - but it worked at the time, and designers didn’t see anything wrong with it.

Today, CSS is so well-supported that there really is no excuse for using tables for layout, and CSS is definitely the better tool for the job. Nevertheless, many web sites still use table-based layouts. This doesn’t mean that this approach is right. It’s simply an old habit that refuses to die!

But just what are the advantages of using CSS instead of tables? Here are a few for you to consider:

Design and Redesign Flexibility

A CSS-based layout ensures that you place all your styles (from cosmetic touches such as font styling, to the major structural rules) in one location.

Change the layout rules you set in that style sheet and you affect every page that is linked to the style sheet. Using a table-based layout locks your page design in at page level. As a result, changing a layout becomes a major problem - one that cannot be resolved simply by changing the style sheet.

Better Accessibility

A table is supposed to be used for tabular data only. For this reason, some assistive devices (such as screen readers) are a bit confused when the content is not presented as expected. In other words, these kinds of devices expect to access tabular data inside a table. If the table is being used for a purpose for which it was never intended, accessibility may be the first casualty. If you use a table for the purposes of layout, content that may appear to be located logically on the screen may not be logical at all when read out by a screen reader. This is a phenomenon known as table linearization.

Quicker Downloads (or Perception of Download)

A table-based page layout often renders more slowly than an equivalent CSS-based layout. This is especially true of pages that have a lot of content. There are a couple of reasons for this. The first is that a table-based layout will generally require much more markup to hold the page together - acting like a scaffold. Using a table-based layout, it’s not just a matter of marking up sections of the page with div elements. This extra markup adds to the page file size, and therefore, the amount of time it takes to download the file.

The second reason is related to the user’s perception of download speed. Browsers don’t download entire web pages in one go. When they ask for a web page, they receive it as a trickle of information. The browser tries to render that information as it arrives. For example, the browser would render the header, then the navigation and finally the body content. If the trickle of information is so slow that there’s a pause halfway through the body content, the browser is still able to display the first half of the body content without any trouble. This isn’t the case using table-based layouts. In a table-based layout, the browser needs to have downloaded all the content in the table before it knows how to accurately render that information on the screen.

For this reason, a CSS-based page layout will usually appear on the screen faster than a table-based layout.

Therefore, you should avoid tables for page layout, but it is fine to use tables for their originally intended purpose: - the presentation of data in a grid.

You can identify some specific areas of the simple table of telephone contact details table (displayed above) - namely the headers, rows, columns and table data cells. This is explained diagrammatically below:

At its most basic level, a table is put together using commands that tell the browser where to start a new row or a new cell within any given row. Since the columns are a natural by-product of this approach, you don’t need to declare each new column.

|table |contains the entire table |

|tr |contains an entire row of a table (hence table row) |

|th |signifies a table header cell |

|td |a general table data cell |

Let’s see how the example table looks in XHTML:

Name

Contact (Home)

Contact (Work)

Location

Jane Bradley

02380 123123

02380 577566

Southampton

Fred Bradley

01273 177166

01273 946376

Brighton

Lionel Rundel

01793 641207

01793 626696

Swindon

The uninspiring default appearance of a table is shown below:

Let’s start by putting some borders around these cells. The impact of the following CSS code is shown below:

td {

border: 1px solid black;

}

Perhaps this is not quite what you expected. That space between each of the cell’s borders is called cell spacing, and you can turn it off by applying the border-collapse: collapse; declaration to the table element.

Let’s turn off the cell spacing and add a little more decoration to our table. We’ll also set the table headings to align to the left of the cell. By default, the content inside table headings (th) is aligned to the centre - which can be confusing.

The results of the suggested changes (and a few other enhancements too) are shown below:

table {

border-collapse: collapse;

border: 1px solid black;

}

th {

text-align: left;

background: gray;

color: white;

padding: 0.2em;

}

td {

border: 1px solid black;

padding: 0.2em;

}

Tables can be used for a variety of purposes, and each type of table may warrant a different look. For this reason, it may be a good idea to use classes in your CSS selectors for tables.

For example, imagine your site includes the following types of tables:

➢ rates

➢ schedule

➢ events

You could set different style rules for each table type in your CSS:

table.rates {

/* declarations for rates tables */

}

table.schedule {

/* declarations for schedule tables */

}

table.events {

/* declarations for events tables */

}

Thus, when you added a table to your XHTML, all you’d need to do would be to give it the appropriate class attribute:

Making Your Tables Accessible

It’s important to think about accessibility when it comes to tables. The question that all web designers ask themselves at some point is, “How on earth does a screen reader read out a table?”

In reading out the content of a table, a screen reader linearizes that content. Linearization simply means that the screen reader reads the content in the order in which it appears in the table’s markup. As an example, consider the table below which displays TV listings. Visually, it’s easy to associate a time-slot with the associated program.

Using a visual scan, we can quickly and easily see when each program starts and ends. Let’s take a look at the markup:

9:30 p.m.-10:00 p.m.

10:00 p.m.-11:00 p.m.

11:00 p.m.-11:45 p.m.

Regional News

Lost

Big Brother

The linearized interpretation of this would be:

9:30 p.m.–10:00 p.m., 10:00 p.m.–11:00 p.m., 11:00 p.m.–11:45 p.m., Regional News, Lost, Big Brother.

We can fix this problem either by changing the orientation of the table (ie. making the program names run down the left and the time slots run down the right), or by marking up the cells that contain the names of the programs using th instead of td and adding a scope attribute to each of the th elements.

summary

A table’s summary attribute is an invisible attribute (it doesn’t render on the screen or when you print the web page) that can be used to provide extra information about the table to assistive devices. Here’s an example of a summary:

When you add a summary, be brief but descriptive. This attribute is a bit like the alt attribute we use for images,

Captioning your Table

If you think the summary attribute seems like a bit of a wasted opportunity because it doesn’t appear in the table’s on-screen display, don’t worry. You can use the caption element for this purpose. Many people would insert a heading (ie. h2, h3) in the XHTML above a table, but the caption element is really the right element to use.

Also, you can use CSS to style it, just as you style headings:

Contact details

Name

Contact (Home)

Contact (Work)

Location

Merging Table Cells

The complication that you’re most likely to encounter as you work with tables is associated with merged table cells. Let’s consider a table layout shown below:

rowspan and colspan

In the example above, the headings of the first and last columns (Date and Contact) span across two rows of the table. Along the top, the table header that has the text Event Details takes up the space of two columns. To achieve this effect, we use the following XHTML attributes:

➢ rowspan

➢ colspan

The example above would be marked up as follows:

Date

Event Details

Contact

Event Description

Approximate Cost

12 July

Committee meeting, deciding on next year's trips

N/A

Bob Dobalina

5 August

Ocean & Sports Diver Theory Course

Call for details

Jeff Edgely

12 August

Murder Mystery Weekend, Cotswolds (no diving!)

£65 pp (accommodation included)

Jill Smith

Note that the first row appears to have three cells (1 column + 2 columns + 1 column = 4). The second row has only two table headers - because the left- and right-most cells in the previous row have been set with a rowspan of 2.

Advanced Accessibility

Badly constructed tables cause some of the biggest accessibility headaches. However, there is a feature you can easily add to your tables to improve access to tabular content for assistive technology like screen readers.

The scope Attribute

When you look at a table of data on the screen, it’s very easy to glance at a header, then scan down the column and see the data that relates to that header. For a blind user who relies on a screen reader to interpret that table data and read it back, it can be tricky to associate data stored deep within a table with its appropriate header. The scope attribute can make this easier.

The scope attribute is applied to a header and has two possible values - row and col.

Date

Event Description

Approximate Cost

Contact

You might use tables that have headers down the left-hand side as well as headers at the tops of the columns like the one shown below:

Here’s the XHTML for the above example:

Train times and departures

Departure Time

Platform

Buffet Coach

Southampton

13:03

12

Yes

Edinburgh

14:47

4

Yes

Newcastle

15:55

7

No

If you start to merge cells (using colspan and rowspan), it gets incredibly tricky to mark the table up in a way that ensures its accessibility. Other attributes are available to help -namely the headers and id attributes which are explained in an article Bring on the Tables by Roger Johansson ().

However, it’s far better to keep your tables simple. When using complicated tables (with rowspan, colspan, headers, and id attributes), it’s still difficult to ensure that it’ll be understood by assistive technology such as screen readers. Even for those readers that do fully support complex tables, there is a high cognitive load on the user to recall the various methods and keystrokes required to access the information.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download