On Apr 9, 2009, at 8:42 AM, Reg Me Please wrote:
> Tables are 2D structures within a 1D tag stream.
> I'd say this is enough to make them unique.
> I would not deprecate <col>.
> How would you define "column properties" in a table?
> Cell by cell?
Please read what has been suggested. In short, I believe the proposals
are more or less like one of these two:
TD:nth-col(3) { /* style for TD starting in 3rd column */ }
or
TD:col(.highlite) { /* style for TD when its COL has an class of
"highlite" */ }
And of course, even today, if you are generating the table dynamically
from a database, it is a fairly simple matter to add a class name to a
TD for a specific data type.
>> COL's lack of parent/descendent relationship to the TD or TH throws
>> normal CSS property inheritance (which is a very key feature of CSS),
>> right out the window. To add it backÃ³in a way that allowed a table
>> cell to inherit from the table columnÃ³would be very complicated,
>> requiring a lot more time and effort than you would probably guess.
>
> CSS can be extended this way: columns CAN BE parents of cells (just
> like
> rows are), despite their position in the syntax tag flow.
> I think that once you accept this concept, everything can fit.
Everything about how CSS selects items to style them assumes one
parent per element. If you think that it is so important to parse
additional style information from a backwards, goofy, ill-conceived
tag, rather than use a more reasonable method, then you are free to
write your own browser to do so. Because I don't think anyone else is
at all likely to do so without significant reason, which you have not
presented.
>> And for anything that gets added to CSS, its usefulness must be
>> balanced against the effort required. You have not shown a use case
>> for doing so that could not be handled just as well (or better) by
>> the
>> ":nth-col()" or ":col()" pseudo-classes that we have been discussing.
>> These new pseudo-classes for selecting a table cell based on its
>> column number would allow styling beyond what is available in COL,
>> and
>> would be much easier to implement.
>
> That's interesting indeed. But IMHO it's also duplicating the <col>
> concept that's already in place.
You've got it backwards. COL does things in ways that are more or less
antithetical to the way CSS does things, and it duplicates (poorly)
something that CSS can do much better in its own way.