Re: [CSS21] 17.5.2.1 Fixed table layout and percentages

On 17/11/2011 14:33, Simon Sapin wrote:
> On 16/11/2011 19:07, Simon Sapin wrote:
>> In section 17.5.2.1 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.
>> Percentages refer to the containing block.

>> 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.
>> So percentage widths refer to the *tentative width* of the table, since
>> its used width is not known yet.

>> this section needs to properly define a table’s tentative width or a
>> similar concept and explicitly use it where appropriate.

In most cases, it's not that there's a "tentative" width floating about 
(unlike when applying min-width/max-width constraints where there really 
is a tentative calculation), it's simply that we take the greater of two 
well-defined values.

However, I agree that there's an ambiguity in the spec about what 
percentage widths on columns refer to, given that columns help determine 
the used width of a table:

[discussing over-constrained cases]:
> It can happen without percentages. Example: a 3-column table with
>
> table { width: 300px }
> #first_column, #second_column { width: 200px }
> /* No specified width for the third column */

This is covered by

   # 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).

The table would be 400px wide (plus extras) and the third column would 
have zero width since there is no remaining space to be distributed. 
(Hence there would be overflow.)

But I see your point.  The spec is a bit muddled in how it explains 
this, particularly as concerns the definition of "remaining horizontal 
table space".

> Or even with percentages that sum under 100%:
>
> table { width: 300px }
> #first_column { width: 200px }
> #second_column { width: 50% }
> /* No specified width for the third column */
>
> What is the width of the third column?

This is more interesting, and the answer depends on what percentages on 
column 'width's refers to.  (In what follows, I'm ignoring the issue of 
borders and border-spacing since these concepts introduce their own 
problems which are being discussed in separate posts.)  Note that in the 
non-normative automatic table layout algorithm such percentages are 
stated as referring to the table width, so it's reasonable to have 
percentages refer in some way to the table width in the fixed layout 
algorithm as well.


The easiest option is to have percentage widths refer to the /specified/ 
width S of the table.

The percentage column widths can be resolved with respect to S and the 
total C of all non-auto columns can be immediately calculated.  If C > S 
then all auto columns are given zero width and the used width of the 
table is C.  Otherwise, the extra space (S-C) can be distributed exactly 
as the spec says: if there is at least one auto-width column then the 
extra space is distributed across all such columns; else the extra space 
could be distributed equally across all columns in the table (meaning 
that the used width of each percentage-width column is a greater 
percentage of the specified table width than that originally specified 
by the author).

It would seem that it's this option that the spec is trying to describe. 
  In Simon's example above, the table would end up being 350px wide, the 
second column would be 150px wide and the third column would have zero 
width.


However, there exists a meaningful (albeit slightly more complex) 
specification for having percentage widths on columns refer to the 
/used/ width of the table:

Let S be specified width of table.
Let T be the total of the widths of all columns whose specified width is 
non-auto and not a percentage.
Let P% be the total (as a percentage) of the widths of all columns whose 
specified width is a percentage.

If P > 100 or (T > 0 and P = 100) then there is no solution possible. 
This case could be left undefined, just as the spec explicitly does for 
performing automatic table layout.

Otherwise:

If (T = 0 and P = 100) or if (S-T)*100/S <= P < 100 then there is a 
well-defined solution in which the used widths of percentage-width 
columns corresponds exactly (up to rounding) to the specified percentage 
of the used table width.

Otherwise:

There is "extra space" that needs distributing, and so S is also the 
/used/ width of the table and the percentage column widths can be 
resolved with respect to S.  We now follow the process described above 
for such a case.

I'm not sure whether the extra complexity of this alternative approach 
is worth it, but IMO the result is nicer in the case (S-T)*100/S <= P < 
100 and probably matches the author's intent more closely.  We see this 
case in action in Simon's example, above; the table would end up being 
400px wide, the second column would be 200px wide (50% of 400px) and the 
third column would have zero width.


Any opinions?  Let's decide which option we want, and then let's figure 
out how to make the spec clearer (in either case).


Note that the same question applies to the automatic table layout, too. 
  17.5.2.2 says:

   # A percentage value for a column width is relative to the table
   # width. If the table has 'width: auto', a percentage represents a
   # constraint on the column's width, which a UA should try to satisfy.
   # (Obviously, this is not always possible: if the column's width is
   # '110%', the constraint cannot be satisfied.)

To me the wording implies that percentage values for column widths are 
relative to the /specified/ value of the table width (else why make a 
special case of 'width:auto' when in fact insoluble constraints can 
potentially arise for any specified width?).


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Monday, 23 January 2012 22:40:11 UTC