W3C home > Mailing lists > Public > www-style@w3.org > November 2011

Re: [CSS21] Fixed table layout and percentages

From: Gérard Talbot <www-style@gtalbot.org>
Date: Wed, 16 Nov 2011 15:14:17 -0800
Message-ID: <b06df7e6a08ec5329a1057cd262fd0e3.squirrel@gtalbot.org>
To: "Simon Sapin" <simon.sapin@kozea.fr>
Cc: "www-style@w3.org" <www-style@w3.org>

Le Mer 16 novembre 2011 10:07, Simon Sapin a écrit :
> Hi,
> In section Fixed table layout:
> Here is how I understand after several reads:
> The table first gets a *tentative width* either from its `width`
> property (if not auto)

> or from the algorithm of 10.3.3 for blocks.

Allo Simon :)

This reference (algorithm of 10.3.3 for blocks) of the spec (recourse of
algorithm of 10.3.3) is not implemented in any browser I know of. On this,
you may want to read

[CSS21] Question on section optional recourse of the algorithm
of 10.3.3
Date: 7 novembre 2011

> Percentages refer to the containing block.

Percentages on 'width' and 'height' on the table are relative to the table
wrapper box's containing block, not the table wrapper box itself.
Section 17.4 Tables in the visual formatting model

> I could not find this written
> anywhere, but I assume that the table wrapper box (see 17.4) is *not*
> the table’s containing block although it is a block container.

I think that the table box's containing block is not the table wrapper
box. I think the table box's containing block is the block container of
the table wrapper box. Otherwise the quote of section 17.4 above with
regards to percentages would not make sense.

> Then some columns get a width, also from `width` properties. Again, I
> guess that the containing block of columns and cells is the table box.

I believe the containing block of columns is that table box.

Table-cells may not have a containing block... you see:
CSS 2.1 does not define how the height of table cells and table rows is
calculated when their height is specified using percentage values.
section 17.5.3

In the non-normative section, we can read:

"A percentage value for a column width is relative to the table width."

> So percentage widths refer to the *tentative width* of the table, since
> its used width is not known yet.

If you could provide the url of an example about this...

I think percentage width of column(s) would require to refer to a non-auto
table width. And it's possible to have impossible situations
(circular-dependent logic) here.

table {width: 200px; table-layout: fixed;}
col#first-column {width: 60%;}
col#second-column {width: 75%;}
leads to a not predictable layout.

table {width: auto; table-layout: fixed;}
col#first-column {width: 25%;}
col#second-column {width: 75%;}
leads to a non-predictable layout or to the recourse of the automatic
table layout algorithm. Often the spec mentions

(...) percentage is calculated with respect to the height|width of the
generated box's containing block. If the height|width of the containing
block is not specified explicitly (i.e., it depends on content
height|width), then the value computes to 'auto'.
or a sentence typically similar.

> The remaining space is then divided for columns that do not have a width
> yet. The remaining space is the tentative width minus everything else.

Everything else being: table borders and column borders and cell borders
and border-spacing.

> (The used width is still not known.) Now what happens if this result is
> negative or zero? Is the width of the remaining columns zero or some
> other arbitrary value?

I assume here that your questions refer to column(s) being set to a
percentage value.

If it's zero, then remaining columns get zero width. If it's negative,
then it's resulting layout is undefined. It's like a situation where a
column width would be set to be 110% of table box width.

> Finally the used width of the table is set to the greater of its `width`
> property and the sum of all its content.


There are some testcases in the CSS 2.1 test suite where the table width
is max(set width, sum of columns width)






Look for separated-border-model-003* and separated-border-model-004*
testcases in


> Whether or not this analysis is correct or close to what browsers do,

There should be more CSS 2.1 testsuite testcases to cover all reasonable
and realistic code 'table-layout: fixed' situations.

What your post does not mention - and this can be a real headache - is
that 'table-layout: fixed' can apply to 4 types of tables:
1- HTML <table> with border-collapse set to separate
2- HTML <table> with border-collapse set to collapse
3- CSS table with border-collapse set to separate
4- CSS table with border-collapse set to collapse

and table-layout: fixed covers several possibilities itself: when table
has an absolute width (eg: table {width: 300px;}), when table has a
relative width (eg: table {width: 40%;}), when table has an auto width.
When table has an auto width, then there are sub-categories of
possibilities too: if one column has a set width (with relative or
absolute width) or if one table cell in first row has a set width
(non-auto absolute width), etc... The whole thing can get quite long and
complex to test.

The CSS 2.1 test suite does not have a lot of testcases on table-layout:

> this section needs to properly define a table’s tentative width or a
> similar concept and explicitly use it where appropriate.
> PS: what is the process for updating specifications that are already REC?

Not sure. I believe errata are just added.

regards, Gérard
CSS 2.1 Test suite RC6, March 23rd 2011

Contributions to CSS 2.1 test suite

Web authors' contributions to CSS 2.1 test suite
Received on Wednesday, 16 November 2011 23:15:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:52 UTC