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

Re: Proposal: :column pseudo-class

From: Laurens Holst <lholst@students.cs.uu.nl>
Date: Mon, 04 Jul 2005 18:31:56 +0200
Message-ID: <42C9647C.9010805@students.cs.uu.nl>
To: Orion Adrian <orion.adrian@gmail.com>
Cc: www-html@w3.org, www-style@w3.org

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 
the table cells can be combined into one when adjecent), that is only 
the case when the field is a reference to something that is unique. E.g. 
this would not be the case for names. So there would need to be a 
semantic clue in HTML as to which rows are of type ‘reference’.

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).

So although my example using ‘id’ and ‘ref’ is verbose and not friendly 
to authors, it seems to me a better solution than the one which matches 
based on cell values, as you propose, because it can at least convey the 
*actual* relations and is machine-generatable and -parsable. With regard 
to forward references, that does not necessarily have to be a problem, 
as long as the ID is there eventually. The HTML label element does not 
have any problems with forward referencing an input field either.

>The beauty of what I'm talking about is that it requires no new HTML
>contructs. Deprecation of colspan and rowspan is all that is
>necessary. The work would then be moved off into CSS.
>  
>
I am not certain that would be in the domain of CSS... It is like, how 
the for= attribute behaves on label elements in HTML is also not part of 
CSS.

By the way, what message did you make the exact proposal in again?


~Grauw

p.s. with regard to sorting of table rows with rowspans - if rows which 
are spanned are taken as a whole during the sorting process, it could be 
made to work sufficiently.

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.
Received on Monday, 4 July 2005 16:32:04 GMT

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