W3C home > Mailing lists > Public > www-style@w3.org > June 2014

RE: [css-flexbox] Behaviour of percentage heights in column direction

From: Greg Whitworth <gwhit@microsoft.com>
Date: Sat, 21 Jun 2014 01:47:40 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Jon Rimmer <jon.rimmer@gmail.com>, www-style list <www-style@w3.org>
Message-ID: <1e9b567ecafc46d7aa338f4678cc7a4e@DM2PR03MB400.namprd03.prod.outlook.com>
> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Friday, June 20, 2014 4:28 PM
> To: Greg Whitworth
> Cc: Jon Rimmer; www-style list
> Subject: Re: [css-flexbox] Behaviour of percentage heights in column
> direction
> 
> On Fri, Jun 20, 2014 at 2:08 PM, Greg Whitworth <gwhit@microsoft.com>
> wrote:
> >> Tab thought that Chrome was doing the right thing here, but I have to
> >> say I much prefer the Firefox/IE behaviour. It seems very useful to
> >> be able to specify an explicit height on the root element of a
> >> widget, then use nested flexboxes within it and have everything flow
> >> down the layout hierarchy appropriately. Particularly, if you can't
> >> do this with an element whose height is controlled only by its "flex"
> >> property, then there are certain layouts that will be impossible
> >> (although grid might cover them).
> >
> > I think that Chrome is not doing the right thing here. The spec for flex basis
> states the following [1]:
> >
> >     # The flex basis is resolved the same way as ‘width’ in horizontal writing
> modes [CSS21]: percentage values of ‘flex-basis’ are resolved against the flex
> item’s containing block,
> >     # i.e. its flex container, and if that containing block’s size is indefinite, the
> result is the same as a main size of ‘auto’.
> >     # Similarly, ‘flex-basis’ determines the size of the content box, unless
> otherwise specified such as by ‘box-sizing’ [CSS3UI].
> >
> > In your example all of the flex containers have a flex-direction of column so
> the "width" in the above statement is actually the height of the items. Also
> since we know that the height of the container is not indefinite those
> percentages should be resolved. I have simplified your example down to just
> one flex example so it is easier to see the problem in the Blink engine [2].
> 
> Why aren't they indefinite?
> 
> ~TJ

Because the height of the container constrains it from being indefinite. The mere fact of having to resolve main size of the flex items requires them to be definite so their children should be able to resolve against that. An even simpler example showing this[1], with only one flex container, the flex item is able to resolve the height after stretching to fill the 100px container. Interestingly though in Chrome the child block isn't able to know its height should be 100px, while in FF/IE this percentage is resolved as expected.

[1] http://jsfiddle.net/6LTwU/5/


Greg
Received on Saturday, 21 June 2014 01:48:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:22 UTC