527285 - implement height/min-height/max-height: -moz-available (standardized as 'stretch')

Status: NEW

(Core :: Layout: Block and Inline, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We should implement the -moz-available value for height/min-height/max-height, just like we implement it for width/min-width/max-width.

Implementing this should proceed in three steps:

 (1) rename nsHTMLReflowState::availableHeight to something that doesn't look like it matches availableWidth (e.g., heightToBreak, although we can probably come up with something better)

 (2) add a new nsHTMLReflowState::availableHeight that's calculated just like availableWidth:
    (a) for the viewport, the height of the viewport
    (b) if the element is fixed height, that fixed height
    (c) otherwise, the availableHeight of the parent minus the element's margin, border, and padding
  In other words, compute what we'd want to use if we were doing vertical text layout.  (This value would actually also be useful if we implemented vertical text.)

 (3) implement -moz-available using the nsHTMLReflowState::availableHeight added in (2) for height/min-height/max-height just like it is implemented using nsHTMLReflowState::availableWidth for width/min-width/max-width.


This value would be particularly useful for columns; it would often produce the height that you wouldn't want columns to exceed; 'max-height: -moz-available' would be useful for multi-column layouts, and would (I presume) cause overflow (additional columns) to the right rather than letting the column length be long enough to require scrolling the container per-column.

The infrastructure would also be useful for vertical text layout.

And it also might be useful for providing certain defaults for flexbox-inside-block layout, but I haven't thought that bit through yet.

Comment 1

[Jonathan Watt [:jwatt]]

This would be very useful for a layout problem I have with the native anonymous content of <input type=number>.

(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #0)
> The infrastructure would also be useful for vertical text layout.
> 
> And it also might be useful for providing certain defaults for
> flexbox-inside-block layout, but I haven't thought that bit through yet.

Given that, CC'ing smontagu and dholbert in case my implementing this would clash with any of their work.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The current definition of nsHTMLReflowState::availableHeight does match availableWidth in one important way: it defines how much space can be used before we want to take an optional break.

Comment 3

[Jonathan Watt [:jwatt]]

Maybe some new containing block units 'cbw', 'cbh', 'cbmin' and 'cbmax' to complement the viewport units 'vw', 'vh', 'vmin' and 'vmax' ( http://dev.w3.org/csswg/css-values/#viewport-relative-lengths ) would be a more flexible mechanism than an 'available' keyword though.

Comment 4

[Simon Montagu :smontagu]

Jonathan, are you actively working on this?

Comment 5

[Jonathan Watt [:jwatt]]

No.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fixing this involves fixing the callers of IsAutoBSize (which was tweaked in bug 1113216 to provide an auto/none/0-like behavior) to do the correct thing for this value, which in some cases may involve propagating it on the nsHTMLReflowState.

Comment 7

[Jonathan Kew [:jfkthame]]

See also IsNonAutoNonZeroBSize (helper used by nsBlockFrame::IsSelfEmpty), which received a similar tweak in bug 1126420.