RE: [CSS2.1] col attributes: XHTML and CSS inconsistency?

Personally, I don't see what the problem would be to convert <col>'s to CSS as part of parsing.
 
<col style="color: red;">
<col style="color: blue;">
 
td:nth-child(1) { color: red; }
td:nth-child(1) { color: blue; }
 
Or, am I missing something fundamental here?

________________________________

From: www-style-request@w3.org on behalf of Tab Atkins Jr.
Sent: Fri 2008-12-26 8:31 AM
To: mongolie2006-w3c@yahoo.fr
Cc: CSS mailiing list W3C
Subject: Re: [CSS2.1] col attributes: XHTML and CSS inconsistency?




On Fri, Dec 26, 2008 at 9:04 AM, Henri de Solages
<mongolie2006-w3c@yahoo.fr> wrote:
>
> Thank you for that.
>   Now, the very idea of a table (long before computer exist) is that cells are the intersection between rows and columns. In fact, the notion of cells is secondary compared to rows and columns in a table. If, at the intersection of the column "mathematics" and the row "John Smith", I write a mark, it means that this mark is related both to maths and to John: probably the mark John got in maths. In informatics, this is called double inheritance, and it is implemented (for instance in C++). Of course, you need rules in case of inheritance conflicts, and this is no more new than doule-inheritance. It had been the case in genetics for millions of years, with at least 2 solutions: dominance (if you got the gene "brown eye" from your father and "blue eye" from your mother, the "blue eye" character is ignored, but can be passed to the further generation), and co-dominance (if your father is black and your mother white, you may look like Obama).
>   To my mind, computers have to manage to follows humans' mind more than the opposite, so that the informatics idea of "table" should be closer to the common idea of table than it is now in CSS's specifications. A table is not a list of rows whose elements would be cells, a table is rather the pair of a list of rows and a list of columns intersecting in cells. The last step is that cells may merge, inheriting the attributes of merged cells (if I merge the cells "John chemistry" and "John physics", it may indicates that the mark written there is a physico-chemistry exam's mark).
>  Therefore I do think the model of table is wrong. Since it's difficult to change the model now, I would suggest another objet, called, say, "doubleentry", that would follow this new model. And the present "table" might be declared deprecated in CSS 4 or 5. Rows and columns would be compulsory, but not cells (non declared cells would just be empty). Cells with column rank outside the range defined for columns would be ignored.

That doesn't solve the problem at all, though.  If we just wanted
cells to inherit more properties from their columns, the existing
<table> model already allows for that potentially.  <doubleentry>
certainly doesn't add any new abilities, at least - the fundamental
issues are still in force.

Namely, since cells are the direct children of rows and not columns,
they are only associated with columns indirectly, in a way that is
apparently difficult to shove upwards in the algorithm.  If you have a
solution to that which would allow cells to be identified with both
their rows and columns while CSS values are still being computed,
please share!  It really would be extremely useful to be able to apply
arbitrary properties to <col>s and have them cascade to the cells.
However, just dreaming up new markup and declaring that it will solve
the problem doesn't work, because this isn't a markup issue.

~TJ