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