W3C home > Mailing lists > Public > www-style@w3.org > October 2002

Re: CSS2.x fixed table layout

From: Rijk van Geijtenbeek <rijk@iname.com>
Date: Sat, 5 Oct 2002 20:40:37 +0200
Message-ID: <10333073763.20021005204037@iname.com>
To: www-style@w3.org

Hello Eric,

On Friday, October 4, 2002 you wrote:


>     I'm a little unclear about how fixed-layout tables are supposed to 
> behave in CSS2 and CSS2.1 (the wording's basically the same between 
> the two), section 17.5.2.  It comes to this: in the absence of 
> explicitly declared column elements, or styles assigned to column 
> elements, do table cells count for the purposes of calculating column 
> element widths, or can cells protrude from their columns?

If column elements are not explicitly added (with COL or COLGROUP or
other elements declared to be "table-column" or "table-column-group"),
what else is a column but the cells that it represents?

The spec says:

<quote>
1. A column element with a value other than 'auto' for the
'width'property sets the width for that column.

2. 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.
</quote>

I don't read here that this only applies to table cells to belong to
an explicitly declared column. Why shouldn't this apply to the
implicit columns that make the cell grid?

> I'm not aware of any language that says one way or the other,

In 17.5.1:

4. A column group box occupies the same grid cells as the columns it
contains.

6. A cell box cannot extend beyond the last row box of a
table or row-group; the user agents must shorten it until it fits.

> and we do have precedent for elements being visually wider than
> their parents.

Hmm... the content of an element may overflow its width in some cases,
but the element in question has not become wider. Nor does it become
smaller if there are floating elements inside it.

>     Is this covered by the restriction that table cells can't have 
> margins, and thus can't have negative margins, and thus can't 
> protrude?  If so, what happens when a column is set to have a width 
> of 100px and a cell within the column has a width of 150px-- does the 
> cell shrink, or the column grow?

In the 'fixed' table-layout model, I would expect the cell to shrink
(and maybe offer an overflow mechanism, for example the contents runs
over the table cell border, or scrollbars appear). This is not what
happens in current browsers though.

>     So I guess my question is actually about how cells and columns 
> interact; once that's answered, I can figure out how fixed-layout 
> tables will behave.  Oops, one other question: is only the first row 
> of a fixed-layout table used to determine widths, or are all rows 
> considered?

Only the first row, as the spec says. See the quote above. Once the
first row has been received, all necessary data to calculate the
column widths for the fixed layout model is available.

Except of course for that nagging case Boris posted.



BTW, I found a little weirdness. Section 17.2 describes the display
values for table elements:

  table-column(In HTML: COL)

Specifies that an element describes a column of cells.

  table-column-group(In HTML: COLGROUP)
  
Specifies that an element groups one or more columns.


But in HTML 4, the COL element can span several columns if you use the
'span' attribute, so it is also a tablecolumn-grouping element.



Greetings,  Rijk                            mailto:rijk@iname.com

Mot du Jour:
Fact is solidified opinion.
Received on Saturday, 5 October 2002 14:36:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:16 GMT