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

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:
> 
> (1) They don't apply.

While I'm generally not a big fan of doing nothing, I'd someday like to be able to scroll a tbody by setting it's max-height and 'overflow:auto'. I think a lot of people would. I'd also like to be able to let individual cells gain a scrollbar in a similar way. But none of that seems likely for CSS2.1, but if there is a chance of doing so in the future, then it might be best to say that they don't currently apply, but that a future version of CSS might have something like that.


> (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.

This is sensible, but seems to have limited usefulness. Like with blocks, the height used is the smaller of 'height' and 'max-height'. But without the ability to have overflow, I have a hard time imagining what I could use that for. I get the most use out of 'max-height' when there is 'height:auto; overflow:auto', but auto-height table cells just keep getting taller with the content, with all 3 height properties just providing a minimum when the content isn't driving the actual height, and I don't seem to get a lot out of that beyond what I get with just 'height'. 

However, that one might be useful if min-height and max-height did do something else useful too. What if max-height constrained the distribution of excess table height, so that it is not added to rows once have already reached the height of any 'max-height' in the cells in that row? Or if the table height is less than the total heights specified for all the rows, it can eat up the space of cells that are taller than their content, but cannot thereby reduce the height of a row below that of any 'min-height' of cells in that row?

> (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. 

> (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'. 'Min-height' still only has an effect if the contents are shorter than it, and then only if 'height' is auto or taller than min-height. The biggest minimum of the cells of a row becomes the minimum for the row in either case, doesn't it? I must be missing some crucial point. In what way do the intrinsic heights get overridden, when the tallest intrinsic height always heightens the row if it isn't tall enough from the other heights already?

> Then there's also the question of what min-width and max-width do on
> rows and the table itself, and what min-height and max-height do on
> columns and on the table itself.  (I prefer the idea that they have
> no effect on rows/columns, but do affect the table.)

Me too. It feels like cheating to put any kind of width on a row directly (or height on a column), when it is really the whole table that is affected by it.

> It's also not clear what percentage values should do in all cases.

I don't have anything to add here.

> Due to the complexity involved, I would tend to prefer leaving this
> undefined in CSS 2.1 (but perhaps making it more explicitly
> undefined).


On Jun 16, 2010, at 10:29 AM, L. David Baron wrote:

> However, there's also a fifth possibility:  a variant of (2) where
> 'min-height' and 'max-height' also contrain the intrinsic heights of
> the cells (like how (4) differs from (3)).  (And *that's* what I
> think Gecko implements for min-width and max-width on cells.)

I'm still confused by (3) and (4). Sorry. I'm just not understanding how those heights are more constrained. It's probably just me, but I'm not seeing it.

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 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?

> (However, I'm not sure we try to say that
> the table height rules are undefined.  We definitely say the width
> rules are undefined.)

Received on Wednesday, 7 July 2010 06:24:36 UTC