W3C home > Mailing lists > Public > public-css-testsuite@w3.org > November 2011

[RC6] fixed-table-layout-001 is incorrect; feedback requested

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Mon, 7 Nov 2011 11:13:13 -0800
Message-ID: <010785a28be300d47d2476d8b0ee3c68.squirrel@cp3.shieldhost.com>
To: "Public CSS test suite mailing list" <public-css-testsuite@w3.org>
Cc: "Arron Eicholz" <arron.eicholz@microsoft.com>



This testcase has a lot of difficulties. And I welcome any feedback from
anyone wrt the issues involved in this testcase.

<meta name="assert" content="If a browser supports fixed table layout
when 'width' is 'auto', a table will size to its containing block, minus
any margin space (modified example from spec section">

The table's width may be specified explicitly with the 'width' property.
A value of 'auto' (for both 'display: table' and 'display:
inline-table') means use the automatic table layout algorithm. However,
if the table is a block-level table ('display: table') in normal flow, a
UA may (but does not have to) use the algorithm of 10.3.3 to compute a
width and apply fixed table layout even if the specified width is

If a UA supports fixed table layout when 'width' is 'auto', the
following will create a table that is 4em narrower than its containing

table { table-layout: fixed;
        margin-left: 2em;
        margin-right: 2em }

The spec says that if width is 'auto', then to use the automatic table
layout algorithm and that a UA may still nevertheless resort to the
algorithm of 10.3.3 and apply a fixed table layout. So, all this to say
that if a testcase can be done, it should have a "may" flag.

2- The code in the testcase uses
border-collapse: collapse;
but there is no border anywhere applied at the table and in the table.
Setting border-collapse: collapse; in the testcase is legal and okay but
not logical and coherent. The only resulting layout effect in doing this
is to zero the border-spacing of the table. So, setting border-spacing
to 0 is much more compliant, coherent and understandable than setting
border-collapse: collapse in the hope to achieve the same result.

3- font: 62.8% Ahem;
The only achieved goal of setting such value is to counter-act the
line-height: 1.2 of Firefox. 62.5% computes to 10px and with 62.8% the
logic is to try to fill the gap above and below the Xes content... and
it does not achieve this anyway.

4- The containing block div has a set width of 200px, the table has set
horizontal margins of 50px and the table (which has one single row and
one single cell) has 10 "X"es in Ahem font. All this adds up perfectly.

So, as coded, the table can not render its content or be rendered in any
other way different than the layout of optional statement in the spec.
The testcase is "doctored" so that it can not fail to achieve the layout
from the optional statement. The testcase does not reflect an
implementation choice of logic (as given by the spec); the testcase is
just too much constrained. So, if the testcase can not fail in achieving
an intended layout, then it does not and can not really test what it was
intended to test in the first place, to begin with.

Generally speaking, a table with a single row that has a single cell
with all kinds of ideal values and ideal constraints is not going to be
very much convincing of anything or even useful or proving the
implementation of an implementation.

5- Finally, I can not see a single browser implementing that optional
recourse of the algorithm in section 10.3.3 and I've run a lot of test,
including these tests:



regards, Gérard
Contributions to the CSS 2.1 test suite:

CSS 2.1 Test suite RC6, March 23rd 2011:

CSS 2.1 test suite harness:

Contributing to to CSS 2.1 test suite:
Received on Monday, 7 November 2011 19:13:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:55 UTC