- From: Sebastian Redl <sebastian.redl@getdesigned.at>
- Date: Sat, 02 Jul 2005 20:32:16 +0200
- 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 UTC