when are tables appropriate?

Tableless design for non-tabular data seems to be a pretty highly
recommended thing to do, but I'm not really sure what consitutes
tabular data and what doesn't... any ideas?

Also, if you do have two pieces of tabular data, would it be okay to
display one within the other? eg. to have a table within a table? Or
is that generally considered "bad form"?

yawnmoth wrote:

Tableless design for non-tabular data seems to be a pretty highly
recommended thing to do, but I'm not really sure what consitutes
tabular data and what doesn't... any ideas?

If you were to send the information to a friend, would you use a text
document, or a spreadsheet? If the former, it's not tabular data ;-)

Also, if you do have two pieces of tabular data, would it be okay to
display one within the other? eg. to have a table within a table? Or
is that generally considered "bad form"?

Can you give an example of tabular data that needs to be nested in
another 'piece' of tabular data?

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/

Now playing: Strawberry Switchblade - Since Yesterday

yawnmoth wrote:

Tableless design for non-tabular data seems to be a pretty highly
recommended thing to do, but I'm not really sure what consitutes
tabular data and what doesn't... any ideas?

Also, if you do have two pieces of tabular data, would it be okay to
display one within the other? eg. to have a table within a table? Or
is that generally considered "bad form"?

yawnmoth,

I'll take a stab at this, but it's very subjective.

In a 'proper' table:
- Everything within one column is somehow logically related.
- Everything within one row is somehow logically related.

A typical example would be the color choices for an automobile, where
columns represent exterior paint color and rows represent interior
upholstery color. Each cell of the table contains 'X', indicating the
combination is available, '-', indicating it is not, or 'O', indicating
you can get it at extra cost.

Another example would be a catalog, with each row representing an
orderable item, and columns for part number, size, color, weight, price,
etc.

Now suppose that in that same catalog, some items have two colors, and
further suppose that, as with the interior/exterior color combinations
for automobiles, not all combinations are available. In this case, it
might make sense to have, within the single cell of the catalog that
represents 'color', an inner table which has rows listing the interior
colors and columns listing the exterior colors, with the cells of that
table showing, via flags, the standard or special-order combinations.

That would be a 'proper' nested table, since both the inner and outer
tables meet the definition, and everything in the inner table is
logically related to the cell of the outer table within which it appears.

In practice, however, the window real estate is rarely sufficient to do
this, especially since you have no idea how big the user's window is.
In the catalog case, most sites seem to defer presenting such complexity
(interior/exterior color combinations) until the user has selected a
specific item, thus allowing detailed data about that item to be
presented on a separate page.

You get into philosophical trouble when you are placing things into a
table solely for the purpose of getting them to appear 'next to' each
other, either horizontally or vertically, rather than because of any
logical relationship between them.

Here's one way to test your table: If you change the ORDER of the rows
or the ORDER of the columns (such as by sorting), is the presentation
still OK? If it isn't, it's probably not a 'proper' table.

Chris Beall

yawnmoth wrote:

Tableless design for non-tabular data seems to be a pretty highly
recommended thing to do, but I'm not really sure what consitutes
tabular data and what doesn't... any ideas?

I was wondering this myself yesterday - I've got a page on a website
showing accommodation rates for the year -

http://www.scottish-logcabin.co.uk/rates.php

which currently doesn't use tables, but I'm going through a site
redesign and I was wondering if the rates info would be appropriate
to show in a table?

Not a big problem, but one that went through my head...

Any suggestions?

Thanks,
Simon

yawnmoth wrote:

Tableless design for non-tabular data seems to be a pretty highly
recommended thing to do, but I'm not really sure what consitutes
tabular data and what doesn't... any ideas?

Rule of thumb:

* Can you put a heading on each column?
* Do you have at least two non-heading rows?
* Does every item in each row have something in common with every other item
in the same row, but not with other rows?
* As previous, but read "column" for "row".

Also, if you do have two pieces of tabular data, would it be okay to
display one within the other? eg. to have a table within a table? Or
is that generally considered "bad form"?

It is very unlikely that nested tables would accurately describe the data
being presented. It is theoretically possible though. What data do you have
that would justify such a presentation? (The odds are that two entirely
separate tables would be better).

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

On Wed, 15 Mar 2006 22:20:34 -0000, Simon <simon.hanmer (AT) gmail (DOT) com> wrote:

yawnmoth wrote:
Tableless design for non-tabular data seems to be a pretty highly
recommended thing to do, but I'm not really sure what consitutes
tabular data and what doesn't... any ideas?


I was wondering this myself yesterday - I've got a page on a website
showing accommodation rates for the year -

http://www.scottish-logcabin.co.uk/rates.php

which currently doesn't use tables, but I'm going through a site
redesign and I was wondering if the rates info would be appropriate
to show in a table?

You need to do something, because at the moment you are using colour alone
to provide information. Switch off styling and all I get is a list of the
months of the year, no indication which is hi/lo/mid season. How will a
colour blind or audio user perceive your data? A table may be an answer
but possibly not the only one.

oops, good point!

I'm guessing it'd be appropriate to use the abbr attribute in <td ..>
in this situation?