Re: Proposal: :column pseudo-class

On 7/2/05, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
> 
> 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>

I'm talking about table semantics and you're giving me presentational
arguments. Presentation can be handled with other properties to give
the same look we have now, but without the problems we have now.

One problem with the last example you gave is that is has a split
index (left arm and bicep).

<tr><th>Location</th><th>Muscle Group</th><th>?</th><th>?</th>
<tr><td>Left Arm</td><td>Bicep</td><td>xxx</td><td>N</td></tr>
<tr><td>Left Arm</td><td>Tricep</td><td>yyy</td><td>N</td></tr>
<tr><td>Right Arm</td><td>Bicep</td><td>aaa</td><td>N</td></tr>
<tr><td>Right Arm</td><td>Tricep</td><td>bbb</td><td>N</td></tr>

You can imagine what that would look like without any styling, but
imagine an additional CSS property that did adjacent cell merges at
presentation time to give us what we're used to. The benefit of this
is that we can sort and otherwise manipulate the table without loosing
data and without the constraints that we have now.

Orion Adrian

Received on Saturday, 2 July 2005 21:59:58 UTC