- From: Anton Prowse <prowse@moonhenge.net>
- Date: Mon, 23 Jan 2012 23:39:19 +0100
- To: www-style@w3.org
- CC: Simon Sapin <simon.sapin@kozea.fr>

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