W3C home > Mailing lists > Public > www-style@w3.org > February 2015

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

From: Greg Whitworth <gwhit@microsoft.com>
Date: Tue, 24 Feb 2015 23:52:13 +0000
To: Daniel Holbert <dholbert@mozilla.com>, fantasai <fantasai.lists@inkedblade.net>, Tab Atkins Jr. <jackalmage@gmail.com>, Rossen Atanassov <Rossen.Atanassov@microsoft.com>
CC: www-style list <www-style@w3.org>
Message-ID: <BN3PR0301MB086862C59B1F2E8910EF5B86A4160@BN3PR0301MB0868.namprd03.prod.outlook.com>
> 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

There are so many similar threads (and some splitting threads) that have impacts on the other threads recently raised by Daniel, is it possible to have a telecon with the editors to resolve these issues? On your above request, I am for resolving percentages wherever possible (keeping things the way they are) as flex is commonly in a multi-pass state I think the intuitiveness for the authors is beneficial.

Thoughts on the telecon?

Received on Tuesday, 24 February 2015 23:52:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:51 UTC