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

For comparison, here's a variant of the testcase, where the containing
block itself has "height:100%". All browsers I've tested honor the
percent-height on the innermost div here:
http://people.mozilla.org/~dholbert/tests/flexbox/compat_tests/percent-height-grandchild-1-ref.html

I'd argue that the "height: 100%" on the containing block in this
variant is no more explicit than the implied "height:auto;
align-self:stretch" on the containing block in the original testcase.
In both situations, the containing block's height may or may not be
meaningfully resolvable (without needing to look at the children),
depending on information about its ancestors; and if it is resolvable, I
think we should honor percent heights on its children.

~Daniel


On 02/05/2014 05:54 PM, Daniel Holbert wrote:
> 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 02:10:31 UTC