W3C home > Mailing lists > Public > www-html@w3.org > July 2005

Re: Proposal: :column pseudo-class

From: Sebastian Redl <sebastian.redl@getdesigned.at>
Date: Sat, 02 Jul 2005 20:32:16 +0200
Message-ID: <42C6DDB0.10008@getdesigned.at>
To: www-html@w3.org

Orion Adrian wrote:

>Couldn't this problem simply be solved by removing the presentational
>attributes "colspan" and "rowspan". This is HTML's problem, not ours
>really. Well there's that and the fact that display: table-* doesn't
>really work. But let's assume it's an HTML problem.
>  
>
colspan and rowspan aren't presentational, they are structural. They are
the key to non-trivial table structures, as are required by, or at least
highly desireable for some data sets. Take, for example, a web shop that
keeps users and shipping data. In third normal form, that is, in the
database, these will be two tables, because each user can have more than
one set of shipping data. The users table contains name and all that
stuff. Each row of the shipping data table contains a reference to the
user it applies to, the address, billing info etc.
It may be desireable to display all users together with all their
shipping data. You basically have three options.
1) Copy the database schema, and have one table for users and a separate
one for shipping data. This is unusable, because a human cannot
correllate these two tables efficiently enough to make sense of them.
2) Copy the schema of an inner join of the tables. This means that the
complete user info is repeated for each set of shipping data. Again,
this is suboptimal. For example, it obfuscates the actual amount of
users. It is hard to read, because there's lots of superfluous and
redundant text. And you have to look at system IDs to find out if two
people with the same name next to each other in the table are actually
two people, or the same with different shipping data.
3) Make a complex table where a single set of cells for the user data is
next to multiple sets of cells for the shipping data.
<table><caption>Users and Shipping Data</caption>
<thead><tr><th>Name</th><th>Age</th><th>Address</th><th>Bank Account
Nr</th></tr></thead>
<tbody>
<tr><td rowspan="2">Harry Potter</td><td rowspan="2">16</td><td>4,
Privet Drive, England</td><td>n/a</td></tr>
<tr><!-- Taking above. --><td>Gryffindor Dormitory, Hogwarts,
Scotland</td><td>713-62442</td></tr>
</tbody>
</tables>

Another example. A fitness centre is storing fitness data about their
customers. The sheet looks like this:
Left Arm:
   Biceps: xxx N
   Triceps: yyy N
Right Arm:
   Biceps: aaa N
   Triceps: bbb N

To present this data in a table, you could use a naive approach:
<table><caption>Strength</caption>
<thead><tr><th>Left Biceps</th><th>Left Triceps</th><th>Right
Biceps</th><th>Right Triceps</th></tr></thead>
</table>
As the amount of muscles gets larger, you'll find that this becomes
confusing rather quickly. A better approach is to use colspan.
<table><caption>Strength</caption>
<thead>
<tr><th colspan="2">Left Arm</th><th colspan="2">Right Arm</th></tr>
<tr><th>Biceps</th><th>Triceps</th><th>Biceps</th><th>Triceps</th></tr>
</thead>
</table>

The attributes need to stay, with all their problems and quirks.

Sebastian Redl
Received on Saturday, 2 July 2005 18:31:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:03 GMT