[css-sizing] `height: stretch` should just behave as `height: auto`

[tabatkins]

The motivating example for height: stretch's behavior is "what height: 100% should have been" - making the element stretch up to fill its container, even if the container to be filled is further up the ancestor tree (so its direct parent has an indefinite height). However, this ends up with several weird implications:

• If two descendants both want to be height: stretch, what happens? This'll cause overflow in a confusing manner, I think.
• If no ancestor is definite-height, it ends up hitting the root, which uses the ICB's height. The screen's height is fairly arbitrary here; it doesn't often actually correspond to what you want an element to do, as in this example

On the other hand, Flex and Grid have useful, reasonable definitions of stretching the height of an element. In the linked example above, for instance, the author could have made the li elements into flexboxes as well; then the a elements would stretch to full height, exactly as desired. (Rather than stretching to the screen's height.)

So it's probably just not worth trying to do height: stretch in some intelligent manner. We should just treat it like 100% minus margins/border/padding, so it only has a useful effect is the immediate parent is definite-height, and otherwise acts like auto.

[fantasai]

We could alternately define that height: stretch behaves as align-self: stretch in the layout modes that have that ability--it's better than defining it as height: 100% since (e.g. in Flexbox) it gives better behavior. For the ones that don't we can define it as height: 100%.

(Other thought: since the original definition was written for block layout, we could just keep it for block layout and cut it off at the BFC boundary... if we can figure out what margin collapsing is supposed to do. But I'm less sure that this is useful, since as you say, most of these cases are good candidates for flex/grid.)

[fantasai]

Forgot to add: using height: stretch allows using align-self to specify fallback alignment when you hit the max-height.

[css-meeting-bot]

The CSS Working Group just discussed height: stretch` should just behave as `height: auto` , and agreed to the following resolutions:

• RESOLVED: height:stretch behave as align self stretch when possible, otherwise revert to auto

The full IRC log of that discussion

<astearns> topic: height: stretch` should just behave as `height: auto`
<astearns> github: https://github.com//issues/1614
<tantek> TabAtkins: the stretch keyword is defined for ... except for height, it tries to do the same thing except with the additional constraints that height has
<tantek> TabAtkins: the effect is that we go up the tree looking for a definite height, and we just add up all the MBP between the element and the ancestor, essentially trying to make it as big as possible without overflowing the parent
<tantek> TabAtkins: this causes at least two problems
<tantek> TabAtkins: 1 what happens if two descenddants whatn height stretch
<tantek> TabAtkins: 2 second problem, if no ancestor is definite height, then we hit the ICB which is the height of the screen
<tantek> TabAtkins: so it's confusing that a height stretch element ends up being one screen height
<tantek> fantasai: or you ate it all up with MBP
<tantek> TabAtkins: yeah MBP would be subtracted from the ICB height as well
<tantek> fantasai: it accumulates them all
<tantek> s/whatn/want
<tantek> s/descenddants/descendents
<tantek> TabAtkins: two possibility, height stretch acts like height auto
<tantek> the other possibility, in layout moves that allow you to set a line with justify-*?
<tantek> TabAtkins: it does give you good behavior when ...
<tantek> TabAtkins: it does most of what was actually requested
<tantek> TabAtkins: in the layout modes where it does not make sense, like block, it just becomes auto
<tantek> ...
<tantek> fremy: that was not the reason that this was introduced
<tantek> fremy: because we cannot use the alignment so we came up with stretch
<tantek> fremy: it does not solve the problem why we created it in the first place
<tantek> fantasai: different issue
<tantek> fremy: oh ok not contains
<tantek> fremy: nm
<tantek> fantasai: what we want is comments from the WG on this, what do you think of this proposal, any other ideas how should we interpret stretch in the block axis.
<tantek> fantasai: we know how it should work in the inline axis
<tantek> iank_: ...
<tantek> fantasai: this and contain have certainly similarities
<tantek> fantasai: contain on something that does not' have an aspect ratio is going to behave as stretch, so whatever stretch does has to be appropriate for that interaction with contain
<tantek> TabAtkins: we haven't fully defined that anyway
<tantek> fantasai: we did
<fantasai> https://drafts.csswg.org/css-sizing-4/#contain-sizing
<tantek> Rossen: you were saying height stretch wouldn't behave the same as justify-self or align-self, in layout modes that are ...
<tantek> TabAtkins: all kinds, we just don't care in .... ?
<tantek> Rossen: like table cells, it would act as height: auto
<tantek> Rossen: for absolute positioning ...
<fremy> (just fixing last ...: I mentioned how we came up with stretch because align:stretch didn't work out for images with aspect ratio; fantasai pointed out this was "contain" not "stretch" though both are similar)
<tantek> TabAtkins: stretch has a value which is that it fills the containing block without offsets
<tantek> Florian: ...
<tantek> TabAtkins: there are a few reasons
<tantek> TabAtkins: we really want width:stretch, because there are times you want to invoke that behavior but width: auto does something different
<tantek> Bert: would it be more easy to set the stretch on the margin or padding?
<tantek> TabAtkins: you can already do margin control but setting those to auto
<tantek> Bert: this I assume to anywhere you have fixed height?
<tantek> TabAtkins: anywhere where alignment properties .... ?
<tantek> Bert: like a case like columns, you have multiple columns, you have the height of the elements, but you don't know which of the elements will be at the bottom of the columns
<tantek> TabAtkins: can't do that now, block flow, but ...
<tantek> Bert: I want to avoid setting it on height because the element might be broken across columns
<tantek> Bert: I still want it stretched to the bottom (edge) but ...
<tantek> Bert: you can just set stretch on the margin at the top or bottom
<tantek> TabAtkins: we did make it work on margins with ... ?
<tantek> TabAtkins: focusing just on height:stretch, any different ideas? any objections?
<tantek> fremy: is your proposal to say that in the cases that ... know, that you will behave as align stretch or in all cases?
<tantek> astearns: proposal is for height:stretch to behave as align height of stretch in those layout modes that define align height of stretch and fallback to height auto otherwise
<Bert> s/with ... ?/with flexbox./
<tantek> fremy: when you have nested stretch? when you have scrollable containers?
<tantek> TabAtkins: doesn't solve either of the initial problems, e.g. two sibling elements stretch
<astearns> s/align height/align-self/
<tantek> TabAtkins: align self stretch knows how to handle itself
<tantek> TabAtkins: grid and flexbox know how to handle multiple align self stretch elements
<tantek> TabAtkins: I don't want to define a feature that causes horrible amounts of overflow
<tantek> TabAtkins: a lot of the use-cases are addressed by just using flex or grid
<tantek> fremy: then why?
<tantek> TabAtkins: it's frustratingly confusing if height and width allow different keywords, and there is reasonable behavior we can define for height: stretch
<tantek> TabAtkins: except no reasonable way to define it for a block
<tantek> fremy: still not entirely sure
<tantek> fremy: it's not useful but it's allowing ... ?
<tantek> TabAtkins: the other bit of it there was a discussion in an earlier telcon about what the fallback value for stretch should be when there is a max-height keeping it from being full height
<tantek> TabAtkins: you set --- align-self ...
<tantek> TabAtkins: helps us avoid having to have a specific flag
<tantek> fremy: ok fair
<tantek> TabAtkins: if the know how height-stretch works
<tantek> astearns: any objections having height:stretch behave as align self stretch when possible, otherwise revert to auto?
<tantek> astearns: hearing no objections
<tantek> RESOLVED: height:stretch behave as align self stretch when possible, otherwise revert to auto
<TabAtkins> s/you set --- align-self .../you set height:stretch, then just use align-self as normal to set the fallback/

[fantasai]

As we were drafting text for this resolution, @tabatkins and I noticed that we had discussed what to do in cases where 'align-self: stretch' applies, but not so much where it doesn't.

Our current draft includes a paragraph defining these cases (where there's no 'align-self: stretch' behavior to hook into, such as the height of block boxes) to match the behavior of '100%', modified to apply to the margin box to effect the desired "fill container" behavior. (This specs the behavior suggested in the earlier #1614 (comment) )

In cases where even percentages can't resolve, it falls back to auto.

This new text still avoids the "blow up all the elements up to the nearest definite-height ancestor" behavior that was previously there, which inspired this issue in the first place; instead, it only references the nearest containing block, same as percentage resolution. And while it can still cause overflow in a container with a height:stretch element along with other children, this is no different than 'width: 100%'.