- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 16 Mar 2010 20:34:27 -0500
- To: Peter Moulder <Peter.Moulder@infotech.monash.edu.au>
- Cc: sam <samuelp@iinet.net.au>, www-style@w3.org
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