[css-flexbox] Honor percent heights on children of stretched flex items (when flex container has fixed height)?

Hi www-style,

QUESTION: In a fixed-height horizontal single-line flex container with a
stretched child, and with a percent-height grandchild inside of that
child, should the grandchild's percent-height be honored?

(tl;dr: I think it should be honored. Chrome & OperaPresto currently
don't honor it, though.)

TESTCASE:
http://people.mozilla.org/~dholbert/tests/flexbox/compat_tests/percent-height-grandchild-1.html

Implementations are currently divided. As noted at the bottom of the
testcase, Firefox and IE do honor the percent-height; Chrome and Opera
(Presto) do not.   (I didn't test WebKit trunk, but I'm guessing it
probably renders like Blink.)

SPEC REFERENCE:
The relevant spec language for percentage "height" values is as follows,
from CSS21:
  # 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

So this spec text provides two conditions under which we'd disregard the
percentage (and it implies that they're equivalent):
 (a) CB height "not specified explicitly"
 (b) CB height "depends on content height"

Clearly (b) is *not* true of my testcase -- the containing block's
height does *not* depend on content. It's a stretched flex item in a
fixed-size single-line flex container, so its height is just the
container's (hardcoded) height.  So, that suggests we should *honor* the
percentage on its child.

However, (a) is a bit iffier -- it's not clear to me what "specified
explicitly" really means. Depending on how much you want to mince words,
you could probably argue either way.

MY ANSWER:
I'd argue that the (b) "depends on content height" condition is what we
should be considering here, because that's really what indicates whether
percent-heights on the children are meaningful (and won't cause feedback
loops).  Plus, the spec seems to provide (b) as a clearer definition of
what it means by (a), so I think it's reasonable to trust (b).

So, I think the Firefox & IE behavior (honoring the percentage) are
correct, because the containing block's height does *not* "depend on
content height", which means we should *not* be treating it as "auto".

Thoughts / objections?

(If my understanding is correct, then I'll go ahead and file this as a
Blink bug, and perhaps also a WebKit bug, if it reproduces there as well.)

Thanks,
~Daniel

Received on Thursday, 6 February 2014 01:55:15 UTC