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

Actually, no, sorry -- I think there may still be an issue here. I still think it might be best if we required a definite "min-height" value, in order to consider a vertical flex item's height as being definite.

Stepping back: if I'm understanding correctly, option B that you referred to (which the CSSWG resolved on) basically has the following two implications:
  (1) content-based "min-height" values do not influence the percent-basis that children are resolved against.
  (2) As a result, content-based "min-height" values do not cause their clamped "height" to be considered indefinite. (Percents can still be resolved against that height, pre-clamping.)

(hopefully that makes sense)

BUT: flexbox goes against the grain here, and it explicitly violates implication #1 here (as described below). So, I'm wondering whether that means it should *also* violate implication #2, for consistency regarding "definite" taintedness.

Specifically: on a flex item in a vertical container, a content-based "min-height:auto" value *does* explicitly influence the percent-basis that its children's percent heights are resolved against -- despite implication (1) above.  This is because percentage heights on a flex item's kids are specced as resolving against the "flexed main size" (height) of the flex item. The flexbox spec considers this flexed main size (height) as definite iff the flex-basis was definite, per flexbox section 9.8.2, *even though* the explicitly-content-based min-height:auto is taken into account when establishing the final flexed size.  So -- hopefully this explains how flexbox violates implication #1 above.

So. Given that, would it make sense to say that "min-height:auto" (& indefinite min-height values) should cause the "flexed main size" to be considered indefinite? i.e. should we change flexbox section 9.8.2 to only consider flexed main sizes as "definite" iff the flex basis *and* its min main-size are *both* definite? (and the max-main-size as well, I suppose)

I'm also OK leaving things as they are, but I think this means we'll have to do multi-pass layout, for any flex item with a percent-height child -- once to measure the auto-height for "min-height:auto" (with an indefinite height), and once to lock in the final size (with the resolved definite height). And that's unfortunate & inefficient. :-/

Thanks,
~Daniel

On 02/24/2015 02:13 PM, Daniel Holbert wrote:
> On 02/20/2015 07:00 PM, fantasai wrote:
>> Here's the thread:
>>   https://lists.w3.org/Archives/Public/www-style/2014Jul/0009.html
>> The resolution was B.
>>
>> Let me know if that's satisfactory or if we still have an issue here.
> 
> Thanks. I think that clears things up, yeah.
> 
> ~Daniel
>

Received on Tuesday, 24 February 2015 22:54:45 UTC