Re: [CSS3-Values] Table cell inheritance

(Apologies for the large amounts of context quoting.)

On Mon, 26 May 2003, Ernest Cline wrote:
> 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.

Yes, but how do you know any of this without attempting to lay out the
document?

You are requiring that any implementation of the cascade have knowledge of
the physical meaning of the properties involved.


> > 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?

Right. It's the hypothetical way of saying "this cell spans n columns".

> 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.

Take the following document fragment:

   <section>
    <section>
     <h> Foooooooooo </h>
     <p class="date"> Monday </p>
     <p> Content ontent ontent. </p>
     <p class="attribution"> <cite> A. N. Other </cite> </p>
    </section>
    <section>
     <h> Bar </h>
     <p class="date"> Tuesday </p>
     <p> Text ext ext. </p>
     <p class="attribution"> <cite> Someone Else </cite> </p>
    </section>
   </section>

...and lay it out like this:

   | Foooooooooo              |              |
   | Monday  | Content ontent |              |
   |         | ontent.        | A. N. Other  |
   | Bar                      |              |
   | Tuesday | Text ext ext.  | Someone Else |

Unless you hard-code the size of the columns, I don't think you can easily
get that layout without using the col-span/row-span properties.

I don't think col-span and row-span are any more semantic than
list-style-type. In fact I'd say there are many more totally unsemantic
cases where they would be used. Indeed, most uses of colspan and rowspan
attributes today aren't semantic, and if we want to move those layouts to
CSS, we're going to need an alternative. Don't forget there's nothing
wrong with table-based layout per se, it's only when said layout is
achieved by butchering supposedly semantic markup that there is a problem.


> > > 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.

My bad. Change the example's stylesheet to:

   tbody { display: table; }
   tbody::before { display: table-column; }


> 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.

No, but the important distinction is that in CSS2.1 the attribution
happens a significant time _after_ any cascade occurs.

Note that in CSS2.1, if you had a child of the <td> which had 'width:
inherit', it would inherit the _auto_ value and not a length. This is a
fundamental change from CSS2 (although in practice it affects few
implementations and probably fewer Web pages), made because the working
group wanted to avoid this very problem of the layout affecting the
cascade. As current and past CSS2 implementations show, implementators
have (understandably) repeatedly failed to implement layout-dependent
inheritance in a reliable and correct way.


> (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 IMHO be better if the entire display-model/display-role split was
rethought. There are currently significantly more combinations that make
no sense than combinations that work and are useful.

(As far as I know no work has been done on this part of the box model
draft since the working group briefly discussed this problem back in the
2002 plenary face-to-face.)

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

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