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

Re: [css3-flexbox] Children of flex items ignoring cross-axis percentage length

From: Daniel Holbert <dholbert@mozilla.com>
Date: Mon, 07 Apr 2014 10:36:36 -0700
Message-ID: <5342E224.1010302@mozilla.com>
To: Greg Whitworth <gwhit@microsoft.com>, fantasai <fantasai@inkedblade.net>, "Tab Atkins Jr." <jackalmage@gmail.com>
CC: "www-style@w3.org" <www-style@w3.org>, "mstensho@opera.com" <mstensho@opera.com>, "ojan@chromium.org" <ojan@chromium.org>
Interesting.

Here's a perhaps simpler case: suppose a vertical flex container has a
flex item with "height: 10px; flex-basis: 50px", and that flex item has
a child with a percent-valued height.

Should the percent height resolve against the 10px specified-height, or
against the flex-basis (which we can reliably know ahead of time is what
its used height will end up resolving to)?

Testcase: http://jsfiddle.net/LcL8U/

CSS21 says this about percent height values:
  # The percentage is calculated with respect to the
  # height of the generated box's containing block.
  # If the height of the containing block is not
  # specified explicitly (i.e., it depends on content
  # height), and this element is not absolutely
  # positioned, the value computes to 'auto'."
http://www.w3.org/TR/CSS21/visudet.html#propdef-height

(We can disregard the second half of this spec text here, since there's
clearly no dependence on content in my or Greg's example, and no browser
seems to be treating the percent height as "auto".)

So the question is, what is the "height of the box's containing block".
Blink seems to be saying it's the specified "height" property, while
Gecko/Trident are using the actual box's height (the flex basis). Since
the CSS21 spec text [quoted above] seems to be talking about box height
rather than the "height" property here, I tend to think the
Gecko/Trident behavior is correct.

~Daniel
Received on Monday, 7 April 2014 17:37:04 UTC

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