Re: [CSS21] 17.5.2.1 Fixed table layout and percentages

Le 23/01/2012 23:39, Anton Prowse a écrit :
> On 17/11/2011 14:33, Simon Sapin wrote:
>> 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.

This is what I meant by "tentative width", with the addition that 
percentages refer to the result of 10.3.3 when the specified/computed 
width for the table is 'auto'.

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

I think that we agree on what the current spec is trying to describe, 
and your description above matches my implementation in WeasyPrint. 
Still, the spec could be made more explicit and readable.


> However, there exists a meaningful (albeit slightly more complex)
> specification [snip...]
>
> 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.

I think that "nicer but more complex" is in the automatic layout 
territory. But it’s fine for me either way, as long as the spec becomes 
clearer. What do others UA do?

Regards,
-- 
Simon Sapin

Received on Tuesday, 24 January 2012 11:57:15 UTC