W3C home > Mailing lists > Public > www-style@w3.org > July 2010

Re: min/max-height on cells and rows (was Re: [CSS21] Height of cell box should not be influenced by 'height')

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
Message-ID: <20100710213105.GA31739@pickering.dbaron.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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:29 GMT