[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%'.

[css-meeting-bot]

The CSS Working Group just discussed height: stretch, and agreed to the following:

• RESOLVED: height-stretch behaves as better 100% where align-self stretch isn't possible

The full IRC log of that discussion

<fantasai> Topic: height: stretch
<fantasai> github: https://github.com//issues/1614#issuecomment-661391733
<fantasai> TabAtkins: A little while ago we added 'stretch' keyword to width/ehight
<fantasai> TabAtkins: width: stretch does what blocks normally do in block layout
<fantasai> TabAtkins: even in cases that currently do fit-content for 'auto'
<fantasai> TabAtkins: the question was what happens if specify for height
<fantasai> TabAtkins: initially tried to do something from an earlier attempt from dbaron
<fantasai> TabAtkins: would increase height of item as much as needed to fill height of closest definite ancestor
<fantasai> TabAtkins: This ended up being weird, potentially blows up further than you want
<fantasai> TabAtkins: took a resolution to make it behave like 'align-self: stretch' wherever that has a meaning
<fantasai> TabAtkins: and in other cases, behaves like auto
<fantasai> TabAtkins: but when editing in realized we could do most of what was wanted
<fantasai> TabAtkins: by treating similar to percentage height when percentages can resolved
<fantasai> TabAtkins: So basically act like slightly smarter 100% (considers margins also)
<fantasai> TabAtkins: when that's possible
<fantasai> TabAtkins: and otherwise fall back to auto
<fantasai> TabAtkins: no extra magic
<fantasai> TabAtkins: filling container when percentage could resolve
<AmeliaBR> q+
<fantasai> TabAtkins: gives better abilities
<fantasai> TabAtkins: this proposed behavior, actiling like 100% minus MBP
<fantasai> TabAtkins: gives an expected and useful behavior for 'stretch' without causing the inflating behavior concerned with earlier
<fantasai> cbiesinger: This makes a lot of sense.
<cbiesinger> q+
<astearns> ack AmeliaBR
<fantasai> AmeliaBR: If you did want the behavior of dealing with a couple parents levels of padding and borders, just describing each level as 'height: stretch', woudl that work?
<fantasai> TabAtkins: Just as percentage resolved against definite size is treated as definite, stretch resolved against such would also be definite
<fantasai> TabAtkins: would then follow up the tree
<astearns> ack cbiesinger
<fantasai> cbiesinger: This is basically renamed fill-available keyword, right?
<fantasai> TabAtkins: yes
<fantasai> astearns: Questions or comments?
<fantasai> dbaron: I guess the one thing, the thing I originally proposed
<fantasai> dbaron: for orthogonal flow stuff
<fantasai> dbaron: somewhat different use case
<fantasai> dbaron: it's a little weird
<fantasai> TabAtkins: At least, I don't think we want that behavior by default, so don't think hooking it into 'stretch'
<fantasai> TabAtkins: if we want that, maybe different keyword
<AmeliaBR> +1 for the proposal. Let's make this as useful as possible.
<fantasai> astearns: So proposed resolution is that height: stretch, when can't behave as align-self: stretch, will behave as 100% but accounting for margns
<fantasai> Rossen__: Would it contribute to any other height sizing algorithms that aren't fixed?
<fantasai> TabAtkins: what do you mean?
<fantasai> Rossen__: If this is just a block wrapped in a block..
<fantasai> Rossen__: grid item has behavior alrady defined
<fantasai> Rossen__: but block inside grid item is now simply defined by the closest fixed container
<fantasai> Rossen__: so if grid item is not fixed, then you have to propagate up
<AmeliaBR> q+ to ask about cases when percentages are very broken
<fantasai> Rossen__: and stretch the size minus marigns borders padding to whatever is in the further ancestry of that thign
<fantasai> TabAtkins: that is explicitly what we are not doing
<fantasai> TabAtkins: this just looks nearest container, same as percentages
<fantasai> TabAtkins: it is exactly identical as 100%, but sizes margin box instead of content box
<cbiesinger> nearest container -> containing block, I think?
<fantasai> Rossen__: ok, then that makes a lot of sense
<astearns> ack AmeliaBR
<Zakim> AmeliaBR, you wanted to ask about cases when percentages are very broken
<fantasai> AmeliaBR: We have a few cases in CSS where percentages aren't doing useful things
<fantasai> AmeliaBR: e.g. cyclic percentage contributes zero, resolves, lots of overflow, is bad
<Rossen__> fantasai: most of these cases are when percentage is not 100%
<dael> fantasai: I think most of those cases wher eyou have problems are those where % isn't 100. If you put 50% you get weird overflow. If you put 100% these resolve
<dael> TabAtkins: Child of a float fills at 100%. There will be weid b/c m/b/p
<fantasai> ScribeNick: dael
<dael> AmeliaBR: I had it in mind with weird %s
<dael> astearns: Other comments?
<dael> astearns: Prop: height-stretch behaves as even better 100%
<dael> astearns: Concern
<dael> astearns: Is it possible for modes that doesn't resold to align:self we're in a corner
<dael> TabAtkins: THis is meant to be same as align-self in those cases. If we didn't haev taht in grid and defined this it should be same. We anticipate extensibe
<dael> fantasai: Where align self doesn't apply are cases where it doesn't make sense. You have a stack of things that are position relative to each other. It's not about if it's impl there, but if it's defined there
<dael> astearns: Okay
<dael> astearns: Obj to height-stretch behaves as better 100% where align-stretch self isn't possible
<dael> RESOLVED: height-stretch behaves as better 100% where align-stretch self isn't possible