W3C home > Mailing lists > Public > www-style@w3.org > December 2003

Re: Column text color

From: Ernest Cline <ernestcline@mindspring.com>
Date: Fri, 12 Dec 2003 18:21:15 -0500
Message-ID: <410-2200312512232115375@mindspring.com>
To: "Boris Zbarsky" <bzbarsky@MIT.EDU>
Cc: www-style@w3.org

> [Original Message]
> From: Boris Zbarsky <bzbarsky@MIT.EDU>

> Ernest Cline wrote:
> > Could you give a reference to that blog entry?
> Sure thing.  <http://ln.hixie.ch/?start=1070385285&count=1>
> Note that that's what kicked off this thread, by the way.... (if you 
> look at Sandy's original post at 
> http://lists.w3.org/Archives/Public/www-style/2003Dec/0015.html).
> > Because I don't see that I agree with that statement, at least not for
> > an HTML- like table structure where at the time a specific table cell
> > is encountered, one could know which row, row-group, column, and
> > column-group it is in as the start tag for those elements have already
> > been encountered.
> Except some of them could have style applied to them, in which case, all 
> bets are off.  For example:
> <table>
> <tr>
>    <td rowspan="2" style="display: block">row 1, col 1</td>
>    <td>row 1, col 2</td>
> </tr>
> <tr>
>    <td>row 2, col ???</td>
> </tr>
> </table>
> Which column should the "row 2, col ???" cell render in?  I believe it 
> should render in column 1 (and does in Mozilla and Opera; IE does not 
> support changing the display of "td" and Konqueror 3.0.3 simply fails to 
> show that table cell, so testing with them is of little use here).  If 
> the display:block rule is removed it should render in column 2.
> > Now if that were not the case, or if CSS were used to decide which
> > row or column a cell was in
> Like in my example?

Actually, your example only changed the display value of that cell.
I would say that it didn't  affect the columniation of any cells.

To quote from CSS 2.1 Section 17.5 Visual layout of table contents

"Although CSS 2.1 doesn't define how the number of spanned rows
or columns is determined, a user agent may have special
knowledge about the source document; a future version of CSS may
provide a way to express this knowledge in CSS syntax."

The question boils down to what is the rowspan and colspan
for the anonymous table-cell object  generated by rule 7 of
Section 17.2.1 Anonymous table objects.  With CSS 2.1,
an implementation would be free to choose any value for rowspan
that would seem reasonable.  Although the td is no longer a "table-cell"
because of the change in its display property, it would be reasonable
for the anonymous table-cell object to acquire the rowspan of that child
if that child's rowspan can be determined. In that way, the side effects
caused by the change in the display property would be minimized.

Unfortunately, this still leaves a problem. If I change your example to:

   <td rowspan="2" style="display: block">row 1, col 1</td>
   <td style="display:block">row 1, col 2</td>
   <td>row 2, col ???</td>

The rules for anonymous table cell objects say that there is but a
single anonymous table cell object that contains both of those <td>'s.
No matter what value of rowspan and colspan is given to that
there is no way for there to be no side effect as the cells form a non
rectangular portion of the unstyled table.

The best I can suggest is to change to Rule 7 for CSS 3 Tables, by
adding the portions between the brackets.:

7) If a child T of a 'table-row' element P is not a 'table-cell' element,
an object corresponding to a 'table-cell' element will be generated
between P and T.  [If the child T has associated with it rowspan
and colspan information, this object contains only this child, and
the object shall have the same spanning information as the child.
Otherwise,] this object spans all consecutive siblings of T that are
 not 'table-cell' elements [which do not have associated spanning

With this change, the specifying of display upon a table cell
element to something other than 'table-cell' will not affect the
presentation of cells such as the "row 2.col???" cell.  It would
appear in the same row 2, col 2 position that it would without

However, even without such a change, I would make the
argument that if selectors such as :column(an+b) were to
be supported, it will need to be done in a way so that the column
referred to would not be affected by the setting of CSS properties.
This implies that if it were to be extended so as to be able to serve
for a generic table, that instead of having anonymous table-cells
span multiple children, they should only span a single child
(including possibly anonymous inline boxes so that:

<e style="display:table-row">Text<f/>Text</e>

would have three table=cells instead of one or three depending upon
how the <f/> element was styled and that it must be the responsibility
of the document language to specify which elements, it any, had a
rowspan or colspan other than 1.

Then to use  the list from Ian's blog, I think you would be able to know
which column an element belongs to at Stage 2 instead of Stage 3

It requires two small changes in the rules that will not be noticed by
anyone using the default styling of (X)HTML nor by anyone who
does not use styling dependent upon the generation of anonymous
table objects. Only those pages dependent upon the generation of
anonymous table-cell objects will be affected and that doesn't bother
me very much if columns can finally be addressed by CSS.

>  > but for table models like the one used by HTML,
> > I fail to see the impossibility.
> For a CSS browser (as the current crop of browsers are) the 
> impossibility is very real....
> > Whether this possibility is a desirability is a separate question
> > and perhaps the blog entry will point out why such an approach
> > would be undesirable.
> No, the blog entry in fact begs for people to come up with a decent way 
> of supporting this, after listing the technical reasons why it's not 
> supported at the moment.

Well I've given a way, altho it does require a small change be made from
CSS2 to CSS3 table handling.
Received on Friday, 12 December 2003 18:26:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:10 UTC