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

On Fri, Dec 26, 2008 at 10:04 AM, Henri de Solages
<mongolie2006-w3c@yahoo.fr> wrote:
>   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.

This is just inherently not easy to do with anything SGML-based.  SGML
and XML and HTML tag soup and related things are all intrinsically
hierarchal.  Everything must have a parent.  What would you propose
the syntax should be for your tables, in HTML and in CSS?  What would
be the parents of the cell elements: the row elements, the column
elements, or neither ("both" is not possible)?  What mechanism would
permit elements to inherit properties from other elements that aren't
their ancestors, and how would this work when the user wants to
dynamically change an element's display property to or from table (or
doubleentry or whatever)?

On Fri, Dec 26, 2008 at 10:40 AM, Rainer Åhlfors
<rahlfors@wildcatsoftware.net> wrote:
> 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?

That fails when colspan is used (although, to be fair, tr.xxx > td {
color: red } fails when rowspan is used).  It also requires you to
hardcode the column numbering: rules like col.myclass { color: red; }
won't work, which is undesirable.  It might be perfectly usable as a
workaround when :nth-child() is reliably supported, though.

Received on Friday, 26 December 2008 15:58:59 UTC