W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2020

Re: [csswg-drafts] [css-sizing] `height: stretch` should just behave as `height: auto` (#1614)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Mon, 27 Jul 2020 21:46:58 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-664655070-1595886417-sysbot+gh@w3.org>
The CSS Working Group just discussed `height: stretch`, and agreed to the following:

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

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

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1614#issuecomment-664655070 using your GitHub account
Received on Monday, 27 July 2020 21:47:07 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:11 UTC