Re: Proposal: :column pseudo-class

Orion Adrian wrote:
> On 7/4/05, Laurens Holst <lholst@students.cs.uu.nl> wrote:
>>Orion Adrian wrote:
>>>>Although that would be rather bothersome to author (you will have to
>>>>create unique identifications for the table cells that get repeated), it
>>>>would retain the actual 'coupling' of table cells, also when not
>>>>adjacent and sorted.
>>>
>>>The coupling is done by matching values, not explicit linking. Linking
>>>simply puts more work on the author.
>>
>>Yes, but I don't think that matching values is desirable... The same
>>value for a field does not imply that it is actually the same (and thus
>>[...]
>>
>>And even then, the table values do not necessarily need to be complete,
>>e.g. it may reference to 'Bill Smith', and want to combine those rows,
>>but there may be also another Bill Smith who has the same name but is a
>>different person (e.g. determined by a different user ID or a different
>>birthdate in another cell, etc).
> 
> In the case you just described yes, there would need to be a semantic
> clue. Might I suggest an attribute value be added to td and th. The

+1, if the table contains date, there's no way for the browser to 
interpret those correctly without the "value" attribute in ISO-8601 
format.

How do you define the format of the "value" attribute? Values "1", 
"10" and "100e-5" can be difficult to sort correctly. ISO-8601 dates 
sort correctly with alpha sorting but floating point numbers are 
hard to detect and sort automatically without a hint about numeric 
data. An easy way would be to define that if the "value" attribute 
starts with "+" or "-", it will be sorted numerically, otherwise it 
will be sorted alphabetically. This, of course, requires content 
authors to use "+" at the start of positive numbers.

Also, to deal with the above described issue where id and name 
combined make the key to decide when to combine the cells, the 
content author would be required to use following markup:

<tr>
   <td value="+5;Smith;Bill">5</td>
   <td value="Smith;Bill;+5">Bill Smith</td>
   ...
</tr>

Such constructs would be required because id and name are combined 
key so to correctly sort a column, both should be available. It's 
easy to automatically generate this kind of output from database but 
it limits the usability of "value" attribute for accessibility 
purposes.

> [...]
> A B1 C1
> A B2 C2
> D E1 F1
> D E2 F2
> 
> A B1 C1
>    B2 C2
> D E1 F1
>    E2 F2
> 
> A
>   B1 C1
>   B2 C2
> D
>   E1 F1
>   E2 F2
> 
> All of those above have the same semantics. So you could have a
> property called row-grouping that would take the values none, inline,
> outline. I'm playing around with the exact needs and syntax, but the
> core idea behind it is there along with the benefits of such an
> approach.
> 
> 1) Easier semantic marking from a data source.
> 2) Allows row and column data manaipulation (sorting, column reordering).
> 3) Shows that values with identical string representations may have
> different values. (because of the added value attribute).
> 4) Allows for alternate presentations more easily than with rowspan and colspan.
> 5) Others I haven't thought of.

I think it's a good target to require that user agent combines the 
fields for display purposes because otherwise sorting the table in 
the client end doesn't make much sense. One remaining issue is what 
to do if a cell could be combined with next one horizontally or 
vertically and one must be selected.

-- 
Mikko

Received on Tuesday, 5 July 2005 12:05:21 UTC