- From: L. David Baron <dbaron@dbaron.org>
- Date: Sat, 10 Jul 2010 14:31:05 -0700
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: Peter Moulder <peter.moulder@monash.edu>, www-style@w3.org
On Tuesday 2010-07-06 23:23 -0700, Brad Kemper wrote: > On Jun 16, 2010, at 10:17 AM, L. David Baron wrote: > > On Wednesday 2010-06-02 17:27 +1000, Peter Moulder wrote: > >> What effect, if any, should 'min-height' or 'max-height' have > >> on table cells or rows? > > > > I can see four possibilities: > > (2) They apply per-element: in other words, for each cell, we > > compute what is approximately a single computed height (which > > may be 'auto'). This isn't quite as straightforward to define > > as it sounds, but it's relatively simple to define in another > > manner: the height of the row is the largest of: > > > > (a) the heights required by the cells and their alignment > > (b) the 'min-height' of each cell or the row > > (c) min('height', 'max-height') for each cell or the row, > > treating 'auto'/'none' as infinitely large > > > > ((b) and (c) require describing how to handle border and > > padding, which is different for cells and for rows, and border > > is different for the separated borders model and the collapsed > > borders model) > > On Jun 16, 2010, at 10:29 AM, L. David Baron wrote: > > > which in turn allows collapsing (b) and (c) into: > > (b) max('min-height', min('height', 'max-height')) for each > > cell or the row, treating 'auto' as zero and 'none' as > > infinitely large. > > [...] (I'm having a little trouble following your comments on #2, but I don't think it's critical that I do.) > > (3) They apply to the whole row, but don't override the intrinsic > > heights. In other words, the height of a row is the larger of: > > > > (a) the heights required by the content of the cells and their > > alignment > > (b) the larger of: > > (i) the largest 'min-height' of the cells or the row > > (ii) the smaller of: > > ((1)) the smallest 'max-height' of the cells or the row > > ((2)) the largest 'height' of the cells or the row > > > > (with the same rules about border/padding inserted > > appropriately) > > Does that actually result in a different rendering than #2? It > seems like it would be the same, but maybe it's just the limits of > my imagination. A simple case where they would be different is the following: <table> <tr> <td style="max-height: 50px; height: 100px"></td> <td style="height: 75px"></td> </tr> </table> With option (2), the max-height on cell #1 constrains only the contents of cell #1, so the table row ends up 75px tall (from the contents of cell #2). With option (3), the max-height on cell #1 constrains the whole row, so the row ends up 50px tall. > > (4) They apply to the whole row, and do override the intrinsic > > heights. In other words, the height of a row is the larger of: > > > > (a) the largest 'min-height' of the cells or the row > > (b) the smaller of: > > (i) the smallest 'max-height' of the cells or the row > > (ii) the larger of: > > ((1)) the largest 'height' of the cells or the row > > ((2)) the height required by the content of the cells > > and their alignment > > > > (with the same rules about border/padding inserted > > appropriately) > > I'm feeling kind of stupid, because this sounds like it still > results in the same rendering. Intrinsic heights still can expand > the cell (and therefore the row) beyond the measures of 'height' > and 'min-height'. In this option intrinsic heights can expand the height of the row beyond any 'height', but not beyond any 'min-height'. Here's an example where the five options give different results (though I used two variables instead of numbers, because in this example there's always a pair that's the same depending on whether A > B or B > A): <table> <tr> <td style="height: 100px; max-height: 50px"> <div style="height: A"></div> <!-- a variable (50px < A < 100px)--> </td> <td style="height: B;"></td> <!-- a variable (50px < B < 100px) --> </tr> </table> Option (1) [does not apply] makes the row height 100px. Option (2) [cell scope, do not override intrinsic] makes the row height the larger of A or B. Option (3) [row scope, do not override intrisic] makes the row height A. Option (4) [row scope, overrides intrinsic] makes the row height 50px. Option (5) [cell scope, overrides intrinsic] makes the row height B. > On Jun 16, 2010, at 10:35 AM, L. David Baron wrote: > > Also, none of my proposals explain how the different possibilities > > influence the rules for distributing excess table height (from the > > 'height') property to the rows. (Distribution of excess > > height/width generally prefers rows/columns that don't have a > > specified height/width, and also happens in proportion to various > > heights/widths.) > > I don't know if my suggestion above about that helps any. I am not > as aware of how space gets distributed and negotiated around as an > implementor would be. I only know that when the numbers don't add > up, I'm likely to get different rendering in different browsers. I don't think I followed the suggestion above. In any case, from the somewhat limited testing of the differences in behavior that I did when I was considering rewriting the relevant code in Gecko (which I'm still considering doing at some indefinite point in the future), I found I thought the IE6 behavior was most sensible, perhaps largely because it was the most similar to the way distribution of excess width was done. > > I think that argues even more strongly for leaving this undefined in > > CSS 2.1. I think trying to define it requires defining the full > > table layout algorithm. > > When will we do that? When somebody has the time to do it? -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Received on Saturday, 10 July 2010 23:35:32 UTC