Tables Vs Lists

From CSS Discuss

Jump to: navigation, search

There have been several debates in the list about when to use ((table))s or lists for formatting data. (This is different from the debate about whether to use tables or divs for presentation, which is discussed in Tables Vs Divs). Although not strictly CSS-related, this may help you decide if data is appropriate for a table, or if it is actually a list of information. From there you can make CSS presentation decisions as necessary.

Although not strictly defined in the HTML 4.0 specifications[1][2], the examples throughout that document suggests the following differentiation:

  • Tables are useful when presenting data with two dimensions of information.
  • Unordered Lists are useful when presenting data with a single dimension of information.
  • Heading lists are useful when you are presenting single pieces of data that gives other data a reference point.
  • Definition Lists are useful when presenting lists of single units of data with explanatory or subsidiary information.

Contents

Two dimensional data -- huh?

A list of data is one dimensional, it contains a number of single values one after another.

However some data is two dimensional, as well as having a number of unique rows, it also has a number of columns with varying values. So for example, if you have a forum listing that contains 10 rows of forums, each row may contain title, last updated, and the number of comments.

TitleLast UpdatedComments
Forum 1Yesterday13
Forum 2Last week9
...

This is the second dimension, making a grid of data that is suited perfectly to a HTML table. The first dimension is down the grid, defining a number of rows, while the second dimension is across the grid, defining a number of attributes of each row.

What about name-value pairs?

The most debatable part of this discussion arises when dealing with name-value pairs, where a value is associated with a heading. Common occurences of this include submission forms (where the label is the name and the field is the value), product statistics, "Who am I" lists of information on blogs, etc.

Name-value pairs are tricky. They can be seen as data with two dimensions -- one dimension is the name, the other is the value. They can also be seen as a list with one dimension, where the name is the dimension, and the value is either supporting information or requested information -- but not necessarily a dimension of its own. There are several ways to approach this:

Use an unordered list

If the name is clearly the strongest part of the name/value pair, it might make sense to simply have the name as the sole dimension, use an unordered list, and identify the name and data with separate tags within the list, if required. This should only be used if it is patently obvious that the name stands out as the important data point. If the name and value compete for importance, I would choose another option.

Use headings

Headings define lists -- typically lists of content, but also lists of data. They can be extremely valuable in situations where the name identifies the purpose of the data, such as on product data sheets or individual personnel records.

Typically, when the name is used to identify the value (or the value's purpose), headings help identify that. This is especially true with forms.

Define the name-value pair as a definition list

A Definition List is ideal for situations where the name's purpose is identified by the value, such as when defining the purposes of keywords used in a certain parameter.

Typically, when the value is used to identify the name's purpose, definition lists can help.

Use tables for name-value pairs with headings

Although a name-value pair typically has a single dimension of data, if the name has one heading, and the value has another, then you have defined two dimensions of data:

  • name1=value1
  • name2=value2

becomes

NameValue
name1value1
name2value2

This is a good use of a table for defining tabular data. Without the headings, though, it makes a harder case for being a multidimensional data set.

What about forms?

Forms are a challenge. Typically they lend themselves to being considered a name-value pair -- not just because they are sent to the server that way, but because typically each field has a heading associated with it.

Typically forms are presented with the label in one "column" and the field in another:

Label: [field] Label 2: [field 2]

HTML gives us the handy <label> tag[3]. Not only does it give us the ability to provide greater accessibility for form fields, it also gives us a convenient tag for styling in CSS. (N.B.: This topic should probably be its own Wiki page.)

This doesn't work well, however, for radio button groups or multiple inputs that belong to a single heading but don't really meet the requirements for a fieldset. For more flexible formatting, headings might be a solution.

Form fields/labels can fall into the heading category, where the label defines the purpose of the field:

<label for="name">Name</label><h3>
<input name="name" id="name" type="text" />

<h3><label for="ssn">Social Security Number</label><h3>

<input name="ssn1" id="ssn" type="text" size="4" maxlength="3" />
    <input name="ssn2" type="text" size="3" maxlength="2" />
<input name="ssn3" type="text" size="5" maxlength="4" />

</code>

<code> Name [ ] Social Security Number [ ] [ ] [ ] </code>

or

||Name||{{[ ]}}|| ||Social Security Number||{{[ ] [ ] [ ]}}||

This lets you place form elements together with a single heading, maintaining the order and relationships between content elements.

Tables make sense if you are defining the form fields within a table of data.A good example is an invoicing system, where each row shows the quantity, item number, description and cost. The final row could contain fields for other quantities and item numbers.

Unordered lists may not work as well, because there isn't a clear winner as to whether the label or the input is more important.

In conclusion

Tables are quite useful for formatting data that has multiple data points in a set, such as date and title. Lists are useful for formatting data with a single data point per set, such as a list of names. Keep in mind that headings define lists as well, so feel free to consider them when working with lists that have supporting content.

Issue

This begs the question of multiple

s and
s. It's perfectly legal, even according to to W3C spec, to have one definition term have multiple definition descriptions; conversely, it's also legal for several definition terms to share a definition. There *is* ambiguity as to where one group of terms and definition ends as result, and for this reason the W3C are adding a third child to definition lists: the <di> (def. item) element, in order to group terms and descriptions together.

I know the W3C moves at a crawl, so let's ignore the impending <di> element for the time being. There's still the entirely legitimate and possible implementation of multiple
s and
s in definition lists, which radically alter the possibilities for styling definition lists. In other words, it's not strictly limited to a name-value *pair*.It can be a name-value relationship, with any number of names-to-values.

Personal tools