- 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