Re: Columns as ancestors [and a digression]

Matthew Brealey wrote:

> L. David Baron wrote:
> > On Fri, 04 Feb 2000 14:19:29 -0800, Matthew Brealey
> > (thelawnet@yahoo.com) wrote:
> > > descendant of some ancestor element A. For the purposes of descendant
> > > selectors, table cells are treated as descendants of table columns. For
> > > all other purposes however, table cells are not descendants of table
> > > columns.
> >
> > This is impossible, because one can't know what elements are table
> > columns until after the cascade has been completed.  (It is truly
> > impossible to add to the current CSS table model, but possibly (??)
> > only because of the rules for anonymous table elements.  However, if it
> > weren't for those rules, it would require complete style resolution on
> > parent elements before cascading of rules that apply to their children,
> > which is a significant limit on implementations.)
>
> The automatic table layout algorithm require several passes anyway, so
> there is no problem finding the column numbers. Furthermore, the fixed
> algorithm will often have its columns specified, so they can be used,
> and also see:
>
> <blockquote
> cite="http://www.w3.org/TR/REC-CSS2/tables.html#fixed-table-layout">
> In the fixed table layout algorithm, the width of each column is
> determined as follows:
>
> A column element with a value other than 'auto' for the 'width' property
> sets the width for that column.
>
> Otherwise, a cell in the first row with a value other than 'auto' for
> the 'width' property sets the width for that column. If the cell spans
> more than one column, the width is divided over the columns.
>
> Any remaining columns equally divide the remaining horizontal table
> space (minus borders or cell spacing).
>
> The width of the table is then the greater of the value of the 'width'
> property for the table element and the sum of the column widths (plus
> cell spacing or borders). If the table is wider than the columns, the
> extra space should be distributed over the columns.
>
> In this manner, the user agent can begin to lay out the table once the
> entire first row has been received.
> </blockquote>
>
> Really?

sure.

In mozilla, fixed table layout does the right thing with the data it has
available.  If at any time it encounters data that invalidates the constraints
already computed, it simply recomputes (that's a gross approximation, there are
all kinds of performance enhancements in there.)  So, the effect is the table
is laid out on a "best-effort" basis with partial data.  If the author has
specified a reasonable table, one in which all column widths are computable
from info in the first row (at worst), then the author gets the one-pass
performance they intended.  If they don't specify the data correctly, they get
degraded performance but still get correct layout according to the fixed table
layout algorithm rules as if the total number of columns were known initially.

I don't have much of an opinion one way or the other about what the spec says,
or ought to say, to make this more clear.  But this is how mozilla behaves
today, and it seems pretty reasonable.

Steve Clark

>
>
> <table style="width: x; table-layout: fixed">
> <tr>
> <td>
> Column 1
> <td>
> Column 2
> <tr>
> <td>
> Column 1
> <td>
> Column 2
> <tr>
> <td>
> Column 1
> <td>
> Column 2
> <tr>
> <td>
> Column 1
> <td>
> Column 2
> ...
> <tr>
> <td>
> Column 1
> <td>
> Column 2
> <tr>
> <td>
> Column 1
> <td>
> Column 2
> <td>
> Column 3
> </table>
>
> [The necessary result is] That is not what I would call laying the table
> out after the first row has been received.
>
> <blockquote cite=ibidem>
> Cells in subsequent rows do not affect column widths.
> </blockquote>
>
> Don't they?

Received on Thursday, 10 February 2000 12:32:31 UTC