Re: percentage heights in tables (section 17.5.3 of the CSS2.1 spec on "table height algorithms")

On Tue, Mar 16, 2010 at 8:28 PM, Peter Moulder
<Peter.Moulder@infotech.monash.edu.au> wrote:
> On Tue, Mar 16, 2010 at 07:25:17PM -0500, Tab Atkins Jr. wrote:
>> On Tue, Mar 16, 2010 at 4:37 AM, sam <samuelp@iinet.net.au> wrote:
>> > section 17.5.3 of the CSS2.1 spec on "table height algorithms"
>> > (http://www.w3.org/TR/CSS2/tables.html#height-layout) states:
>> >
>> > "CSS 2.1 does not define how the height of table cells and table rows is
>> > calculated when their height is specified using percentage values."
>> >
>> > Why? Would it not be reasonable for the height of a row to be relative to
>> > the height of the table, height of a cell relative to height of its row or
>> > sum of the heights of the rows it spans?  [...]
>>
>> Often, "does not define" in CSS 2.1 means "browsers did all sorts of
>> crazy things, and we decided not to try and stabilize the behavior at
>> this time".
>>
>> Your suggestions do seem reasonable, I think.
>
> I will just note that it does add a little to the implementation cost, in that
> an implementation would prefer to know how high a cell/row is before they know
> how high the row/table is.
>
> The fact that it's only a minimum height actually makes things harder, because
> it makes it harder to work out which rows heights are a percentage of the table
> height, which we need because we want to say "these rows sum to 400px, while
> the others sum to 60%, so 400px must be 40% of the table height, so we can
> interpret a height of '10%' as '100px'".  Because it's just a minimum, the row
> will be determined either by its minimum percentage or minimum fixed height
> depending on how tall the table is (i.e. by whether the percentage or the fixed
> height is greater), so you pretty much have to sort by the ratio of the two
> (i.e. sort by table height cutoff point), and then table layout is no longer
> linear time.  However, I believe that's mostly an academic point: I expect
> you'd need a really huge number of rows for the sort time to dominate.
>
> The main point is that it does add more implementation effort than you'd
> expect, and at the moment I believe there are still more significant issues
> with tables both in the spec and in the extent to which the table spec is
> implemented in common CSS user agents, so I would expect percentage row heights
> to be widely implemented soon.

I assumed that it would follow the standard rules for percentage
heights, in that, say, percentage row heights would only 'work' if the
table had a *definite* height.  It wouldn't try to infer what the
percentage would have to mean based on other row heights.  Essentially
it would work exactly as if the table elements had normal, non-table-*
display types.  Then the value obtained from that calculation would be
fed into the standard table row/cell height calculations.

~TJ

Received on Wednesday, 17 March 2010 01:35:20 UTC