- From: Daniel Holbert <dholbert@mozilla.com>
- Date: Wed, 05 Feb 2014 17:54:48 -0800
- To: www-style <www-style@w3.org>
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