- 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>
> 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? Greg
Received on Tuesday, 24 February 2015 23:52:41 UTC