W3C home > Mailing lists > Public > public-css-testsuite@w3.org > February 2010

Re: Questions about microsoft tests (3nd version)

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 01 Feb 2010 15:11:32 -0800
Message-ID: <4B675FA4.8080502@inkedblade.net>
To: Arron Eicholz <Arron.Eicholz@microsoft.com>
CC: Robert Stam <robert@tallcomponents.com>, "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
On 02/01/2010 02:37 PM, Arron Eicholz wrote:
> Robert Stam wrote
>> 11) ---------
>> chapter_17\table-height-algorithm-005.xht
>> CSS 2.1 specification does not specify how extra table height space should be
>> distributed over the rows. Since a cell-height percentage computes to auto,
>> all rows will get an equal part of the remaining space. A more sophisticated
>> algorithm could inspect cell and row percentage heights and try to satisfy
>> them.
> The spec does state how height percentage works however. Percentage is calculated
> off the containing block in this test case that is the table element. This is
> defined by section 10.1 #2 since table is a block level element. I believe that
> the spec is incorrect in stating that percentage is undefined. That isn't true,
> it is defined. That undefined clause needs to be removed from 17.5.3 paragraph 2,
> the last sentence or it needs to be clarified further.

It is stated to be undefined not because you can't come up with an interpretation
for it, but because the spec intends for the behavior in this case to be undefined.
The behavior of percentage heights and widths in tables is complicated (what happens
if you specify 125%?), and for CSS2.1 the CSS Working Group explicitly chose not to
attempt to define it. It is allowed to treat percentage heights for table cells as
'auto'. It is allowed to attempt to satisfy them according to some algorithm. The
CSS2.1 spec explicitly leaves this up to the UA.

Received on Monday, 1 February 2010 23:12:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:19 UTC