W3C home > Mailing lists > Public > www-style@w3.org > April 2012

Re: [CSS21] Fixed table layout and percentages

From: Gérard Talbot <www-style@gtalbot.org>
Date: Tue, 17 Apr 2012 04:48:44 -0400
Message-ID: <c1c966ac3c8744bacd248754ab7a5315.squirrel@ed-sh-cp3.entirelydigital.com>
To: "Simon Sapin" <simon.sapin@kozea.fr>
Cc: "www-style@w3.org" <www-style@w3.org>

Le Lun 16 avril 2012 21:39, "Gérard Talbot" a écrit :
> Le Mer 16 novembre 2011 19:14, "Gérard Talbot" a écrit :
>> Le Mer 16 novembre 2011 10:07, Simon Sapin a écrit :
> [snipped]
>>> 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
>> http://www.w3.org/TR/CSS21/tables.html#height-layout
>> In the non-normative section, we can read:
>> "A percentage value for a column width is relative to the table width."
>> http://www.w3.org/TR/CSS21/tables.html#auto-table-layout
>>> 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.
>> eg.:
>> table {width: 200px; table-layout: fixed;}
>> col#first-column {width: 60%;}
>> col#second-column {width: 75%;}
>> leads to a not predictable layout.
> I've tested this to be sure.

This is the test:


Top row (with "1st" and "2nd")is the tested table.
Bottom row (with "120px" and "150px") is references (reliable measurements).

> Opera 11.62 will give a 120px width to the first column and then will give
> the remaining available width to the second column: 200px - 120px = 80px.

IE8 does the same as Opera and gives a 120px width to the first column.

> Firefox 11.0 and Chrome 18.0.1025.162 do something else.
> They calculate the ratio for each column and compute in this manner:
> First column gets: 200px mult by (60/(60+75)) = 89px
> Second column gets: 200px mult by (75/(60+75)) = 111px
> I will verify eventually with IE8 and Konqueror 4.8.2; I do not have IE9.

Konqueror 4.8.2 does what Firefox 11 and Chrome 18 do.

> No browser so far did what I feared: give 120px for the first column and
> then 150px for second column and then apply the "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)."
> and change the width of the table from the 200px declared, specified to
> 270px (sum of columns width).
> [snipped]
>>> 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.

Another example but this time more complex and an overconstrained table:


Top row (with "1st", "2nd", "3rd" and "4th") is the tested table.
Bottom row (with "ref"s) is references (reliable measurements).

Sum of columns as specified:
68px (17%) + 100px + 180px (45%) + 150px ==  498px
which is greater than 400px. So, new calculations for first and 3rd column

400px - 100px - 150px == 250px (remaining width space not yet distributed)
which will be distributed among first and 3rd column at prorata of columns
width percentages specified.

Firefox 11.0, Chrome 18.0.1025.162, Opera 11.62 and Konqueror 4.8.2 do
that; I will check IE8 later. In the test, there is a 1px difference which
is only due to different fractional pixel roundings in browsers.

This particular way of rendering an overconstrained table is *not*
explained in section

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 Tuesday, 17 April 2012 08:49:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:14 UTC