Open Bug 527285 Opened 15 years ago Updated 16 hours ago

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

Categories

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

enhancement

Tracking

()

ASSIGNED

People

(Reporter: dbaron, Assigned: dholbert)

References

(Depends on 1 open bug, Blocks 2 open bugs, )

Details

(Keywords: dev-doc-needed)

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.
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.
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.
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.
Blocks: 947365
Jonathan, are you actively working on this?
Flags: needinfo?(jwatt)
No.
Flags: needinfo?(jwatt)
Summary: implement height/min-height/max-height: -moz-available → implement height/min-height/max-height: fill (-moz-available)
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.
See also IsNonAutoNonZeroBSize (helper used by nsBlockFrame::IsSelfEmpty), which received a similar tweak in bug 1126420.
Priority: -- → P3
Blocks: 567039
Blocks: 1693399
Severity: normal → S3
Depends on: 1872755
Summary: implement height/min-height/max-height: fill (-moz-available) → implement height/min-height/max-height: -moz-available (standardized as 'stretch')

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

Assignee: nobody → dholbert
Status: NEW → ASSIGNED

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

Type: defect → enhancement
Flags: needinfo?(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).

Flags: needinfo?(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.)

You need to log in before you can comment on or make changes to this bug.