527285 - implement height/min-height/max-height: -moz-available (i.e. making it fully an alias of 'stretch')

Status: ASSIGNED

(Core :: Layout: Block and Inline, enhancement, 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.

Comment 8

[Daniel Holbert [:dholbert]]

Tentatively self-assigning, in the interests of paving the way for bug 1872755 to address bug 1886561.

Comment 9

[Sebastian Zartner [:sebo]]

Daniel, based on the new summary and the description, this looks like a duplicate of bug 1789477 (or the other way round, as this one's older and has more context).
If that's the case and it's decided to keep this bug open, it should block bug 1789467 and the URL needs to be updated to https://drafts.csswg.org/css-sizing-4/#sizing-values.

Sebastian

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Sebastian Zartner [:sebo] from comment #9)

Daniel, based on the new summary and the description, this looks like a duplicate of bug 1789477 (or the other way round, as this one's older and has more context).

Not quite. There are three (at least) distinct but related things to do in this neighborhood. Here's how I'm envisioning the split:

(1) This bug here is just about making the existing -moz-available keyword work properly (instead of behaving as auto) for height and min-height and max-height; in particular, being treated as an actual pixel value when the containing block has a definite height.
(2) Bug 1789477 is about shipping the new/standardized keyword name which is stretch (possibly just as an alias)
(3) Bug 1872755 is about adding support for the -webkit-fill-available keyword (probably just as an alias)

I'm most concerned with (3) for the moment since it's causing compat pain, but (2) would be nice as well. They both depend on (1) though (this bug).

Comment 11

[Daniel Holbert [:dholbert]]

Evolution of the breakdown in comment 10: I just posted a new plan in bug 1872755 comment 9 where I'm swapping the order of (1) and (3) from comment 10 here -- i.e. shipping -webkit-fill-available first and fixing -moz-available last. (That last part is still this bug, but in the way I'm envisioning it now, it'll essentially just be an aliasing/dead-code-removal action at that point.)