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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 20 Jun 2014 16:27:48 -0700
Message-ID: <CAAWBYDCF-+H8oz54YOZ5DJhh3-VFiwFn4z5s0dbOX0Uk3_7gXA@mail.gmail.com>
To: Greg Whitworth <gwhit@microsoft.com>
Cc: Jon Rimmer <jon.rimmer@gmail.com>, www-style list <www-style@w3.org>
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?

Received on Friday, 20 June 2014 23:28:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:43 UTC