Re: [CSS3-Values] Table cell inheritance

Ian Hickson wrote:

> On Sun, 25 May 2003, Ernest Cline wrote:
> >
> > I don't see the problem myself.
> Assume that any elements in the example below have 'display' values equal
> to their tag names.
> Take:
>    <block>
>     <table>
>      <table-column/>
>      <table-cell> TEST </table-cell>
>     </table>
>    </block>
> ...and:
>    block { color: green; }
>    table-colum { color: red; }
>    table-cell { color: table-inherit; }
>    table-cell::outside { display: block; }
> What color is the cell?
> How do you know, without attempting a full layout including
> pseudo-elements?

Given the rules for anonymous table objects (CSS 2 Section 17.2.1) 
Declaring table-cell::outside {display:block;} means that between table-
cell::outside and table-cell there is an anonymous table and an 
anonymous table-row. (There is also an anonymous table cell containing 
the table-cell::outside.)  As such since color is not defined for any 
of its table superiors, table-inherit would have the same effect as 
inherit and it would have the computed value of its parent element, 
table (green in user agents for which the default value of color is 

(Sidenote #1: I see tremendous potential for bloat caused when 
combining the effect of the rules for anonymous table markup and the 
proposed ::outside pseudo-element of the CSS3 Generated and Replaced 
Content Module.  For example, use of TD::outside with an HTML table 
will cause the creation of an anonymous table-row and an anonymous 
table between the TD and the the TD:outside and the creation of an 
anonymous table-cell between the TD:outside and its TR parent unless 
the author of the document took the care to also specify
  TD::outside {display:table-cell}
  TD          {display:block}
Do we really want to make it so that a simpler declaration will cause 
more work for the user agent? It might be desirable for this reason to 
prohibit or ignore an ::outside pseudochild on elements with a display 
role of table-caption, table-cell, table-column, table-column-group, 
table-footer-group, table-header-group, table-row, or table-row-group.)

> Here's another example:
>    <table>
>     <table-column/>
>     <table-column/>
>     <table-column/>
>     <table-cell/>
>     <table-cell> TEST </table-cell>
>    </table>
>    table-column:nth-child(1) { color: red; }
>    table-column:nth-child(2) { color: red; }
>    table-column:nth-child(3) { color: green; }
>    table-cell:nth-of-type(1) { col-span: 2; }
>    table-cell:nth-of-type(2) { color: table-inherit; }
> Without having actually implemented and used the table layout algorithm,
> how do you know which column the second cell is in?

Where is this col-span property? Is it in a hypothetical CSS3 Tables 
module? (BTW, any idea on when a CSS3 Tables module WD might make its 
appearance?) It certainly is not is CSS2. In any case, since things 
like column and row position and column and row span are semantic and 
not presentational, specifying those should be left to markup to do, 
not CSS in my opinion.

> > 1) Which table superiors (table-row, table-(row|head|foot)-group, table-
> > column, table-column-group, and table) a table-cell has is determined by
> > markup.
> This isn't the case.
>    <table>
>     <col/>
>     <tbody>
>      <tr>
>       <td> TEST </td>
>      </tr>
>     </tbody>
>    </table>
> ...with:
>    tbody { display: table; }
>    tr::before { display: table-column; }
> Here the markup doesn't have any control over the relationship between the
> cell and the column.

Use of any of the table-* display-role values other than that which an 
element normally has disrupts any information about table superiors 
that markup might provide.  As such, the rules given by CSS2.1 17.2.1 
(Anonymous table markup) would have to be used.  In this case, the TD 
element would have have as its table-superiors, the tr element as its 
table-row and tbody as its table.

The table-column that you are making tr::before be (which isn't 
possible in CSS2, but is possible in the CSS3 G&RC Module WD, so I'll 
try to adapt the rules of anonymous table markup given in CSS2 to your 
example) would be contained in an anonymous table since its parent (tr) 
is not a table. Since this anonymous table is a child of the TR element 
and is not a table-cell, the anonymous table would be contained in an 
anonymous table cell which would be the child of the TR element.  
Therefore the table-column given by tr::before belongs to a table 
contained in a sibling table-cell of the TD element in the example 
above and as such is not a table superior of the TD element.

Now if you had tbody::before { display: table-column;} that would be a 
child of tbody and therefore would be a table column in the table that 
TD element is in which I presume is the situation you were trying to 
create.  However, if table-inherit is going to inherit computed values 
from tbody::before in this case, it would also make sense that using 
your example with the following CSS:
  tbody         { display: table;
                  width  : 200px }
  tbody::before { display: table-column;
                  width:   100px; }
  td            { width:   auto; }

that the actual value of the width of the td is 100px and not 200px. If 
CSS affects the determination of which column and row a table-cell 
belongs to, then with existing CSS properties and values, even without 
the introduction of table-inherit, a determination must be made as to 
which row and column a cell belongs to in order to assign values. This 
requirement is not something that can be attributed to table-inherit.

(Sidenote #2: Might it not be better for 'none' in CSS 3 Box to be a 
property of display-model rather than display-role? It would seem to me 
that it would be more useful to preserve display-role rather than 
display-model where none is assigned intermittently by scripting on an 
interactive basis. It also seems to me that the effect of none is more 
one of display-model than display-role.)

(Sidenote #3: The CSS implementation of tables has a distinct table-row 
bias. If someone wanted to markup a table in a markup language that 
used table-columns instead of table-rows to hold the table cells, CSS 
cannot support the presentation of that choice without resorting to 
nested tables.  Hopefully, CSS3 Tables will remedy this minor defect.)

> I agree that some solution would be useful. I just haven't seen or thought
> of a decent workable one.

The desirablity of making it easily workable is one reason why I 
assumed that specification of which row and column a table cell belongs 
to markup and not styling. Absent that assumption (which is a valid 
assumption for CSS2 in my opinion, despite the comments in Section 
17.5.0, since it fails to provide a mechanism for determining rowspan 
or colspan in CSS), determining the computed value of a property with a 
specified value of table-inherit becomes more 
complicated, but that is hardly the only complication that is 
introduced as a result.

Received on Monday, 26 May 2003 13:18:09 UTC