- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Aug 2017 14:29:51 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <astearns> topic: height: stretch` should just behave as `height: auto`<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/1614<br> <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<br> <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<br> <tantek> TabAtkins: this causes at least two problems<br> <tantek> TabAtkins: 1 what happens if two descenddants whatn height stretch<br> <tantek> TabAtkins: 2 second problem, if no ancestor is definite height, then we hit the ICB which is the height of the screen<br> <tantek> TabAtkins: so it's confusing that a height stretch element ends up being one screen height<br> <tantek> fantasai: or you ate it all up with MBP<br> <tantek> TabAtkins: yeah MBP would be subtracted from the ICB height as well<br> <tantek> fantasai: it accumulates them all<br> <tantek> s/whatn/want<br> <tantek> s/descenddants/descendents<br> <tantek> TabAtkins: two possibility, height stretch acts like height auto<br> <tantek> the other possibility, in layout moves that allow you to set a line with justify-*?<br> <tantek> TabAtkins: it does give you good behavior when ...<br> <tantek> TabAtkins: it does most of what was actually requested<br> <tantek> TabAtkins: in the layout modes where it does not make sense, like block, it just becomes auto<br> <tantek> ...<br> <tantek> fremy: that was not the reason that this was introduced<br> <tantek> fremy: because we cannot use the alignment so we came up with stretch<br> <tantek> fremy: it does not solve the problem why we created it in the first place<br> <tantek> fantasai: different issue<br> <tantek> fremy: oh ok not contains<br> <tantek> fremy: nm<br> <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.<br> <tantek> fantasai: we know how it should work in the inline axis<br> <tantek> iank_: ...<br> <tantek> fantasai: this and contain have certainly similarities<br> <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<br> <tantek> TabAtkins: we haven't fully defined that anyway<br> <tantek> fantasai: we did<br> <fantasai> https://drafts.csswg.org/css-sizing-4/#contain-sizing<br> <tantek> Rossen: you were saying height stretch wouldn't behave the same as justify-self or align-self, in layout modes that are ...<br> <tantek> TabAtkins: all kinds, we just don't care in .... ?<br> <tantek> Rossen: like table cells, it would act as height: auto<br> <tantek> Rossen: for absolute positioning ...<br> <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)<br> <tantek> TabAtkins: stretch has a value which is that it fills the containing block without offsets<br> <tantek> Florian: ...<br> <tantek> TabAtkins: there are a few reasons<br> <tantek> TabAtkins: we really want width:stretch, because there are times you want to invoke that behavior but width: auto does something different<br> <tantek> Bert: would it be more easy to set the stretch on the margin or padding?<br> <tantek> TabAtkins: you can already do margin control but setting those to auto<br> <tantek> Bert: this I assume to anywhere you have fixed height?<br> <tantek> TabAtkins: anywhere where alignment properties .... ?<br> <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<br> <tantek> TabAtkins: can't do that now, block flow, but ...<br> <tantek> Bert: I want to avoid setting it on height because the element might be broken across columns<br> <tantek> Bert: I still want it stretched to the bottom (edge) but ...<br> <tantek> Bert: you can just set stretch on the margin at the top or bottom<br> <tantek> TabAtkins: we did make it work on margins with ... ?<br> <tantek> TabAtkins: focusing just on height:stretch, any different ideas? any objections?<br> <tantek> fremy: is your proposal to say that in the cases that ... know, that you will behave as align stretch or in all cases?<br> <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<br> <Bert> s/with ... ?/with flexbox./<br> <tantek> fremy: when you have nested stretch? when you have scrollable containers?<br> <tantek> TabAtkins: doesn't solve either of the initial problems, e.g. two sibling elements stretch<br> <astearns> s/align height/align-self/<br> <tantek> TabAtkins: align self stretch knows how to handle itself<br> <tantek> TabAtkins: grid and flexbox know how to handle multiple align self stretch elements<br> <tantek> TabAtkins: I don't want to define a feature that causes horrible amounts of overflow<br> <tantek> TabAtkins: a lot of the use-cases are addressed by just using flex or grid<br> <tantek> fremy: then why?<br> <tantek> TabAtkins: it's frustratingly confusing if height and width allow different keywords, and there is reasonable behavior we can define for height: stretch<br> <tantek> TabAtkins: except no reasonable way to define it for a block<br> <tantek> fremy: still not entirely sure<br> <tantek> fremy: it's not useful but it's allowing ... ?<br> <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<br> <tantek> TabAtkins: you set --- align-self ...<br> <tantek> TabAtkins: helps us avoid having to have a specific flag<br> <tantek> fremy: ok fair<br> <tantek> TabAtkins: if the know how height-stretch works<br> <tantek> astearns: any objections having height:stretch behave as align self stretch when possible, otherwise revert to auto?<br> <tantek> astearns: hearing no objections<br> <tantek> RESOLVED: height:stretch behave as align self stretch when possible, otherwise revert to auto<br> <TabAtkins> s/you set --- align-self .../you set height:stretch, then just use align-self as normal to set the fallback/<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-319690023 using your GitHub account
Received on Wednesday, 2 August 2017 14:29:51 UTC