Re: [css3-flexbox] Should intrinsic size definitions account for flex? (was Re: Should "align-self:stretch" have any effect on main-size?)

On 08/20/2013 05:12 PM, L. David Baron wrote:
>> Consider this testcase: 
>> http://people.mozilla.org/~dholbert/tests/flexbox/can-stretch-affect-main-size-1.html
>>
>>
>>
>> 
That testcase contains two examples, which only differ in their
>> "align-items" value on the outermost (vertical) container.
> 
> I think this testcase also raises a second question, which is 
> whether the very simple definitions of intrinsic size in 
> http://dev.w3.org/csswg/css-flexbox/#intrinsic-sizes are really 
> correct.  A definition that accounted for the values of 'flex' 
> (perhaps in similar ways to the ways table intrinsic width 
> computation accounts for percentage widths on cells/columns) might
>  have led to a more sensible preferred size for the inner flexbox 
> here, and thus avoided the problem entirely.

dbaron makes a good point.

To elaborate slightly: part of the what's causing weirdness here is
the fact that my testcase's inner (horizontal) flex container has to
compress one of its children to *less that child's intrinsic width*,
when we give the container *its* intrinsic width.  And that makes that
child wrap its text & need several lines of height.  And as a result,
the flex container's height-when-given-its-intrinsic-width is several
lines tall.

(In a bit more detail: in my testcase, the horizontal flex container
has two children -- one with text, and one that's empty -- and the
flex container's intrinsic width comes entirely from the child with
text. BUT, when we give the container that intrinsic width, the text
ends up needing to wrap, because the two children both have "flex: 1"
(aka "flex: 1 1 0%"), which splits the container's width equally
between the children.  So: when we give the horizontal flex container
its intrinsic width, the child with text ends up with half of the
width that it wants, and it has to wrap.)

So this means, as we stretch our horizontal flex container past its
intrinsic width, the need for text-wrapping goes away and we *reduce*
the amount of height that it needs. (Putting that in terms of the
outermost (vertical) flex container: when we stretch its flex item in
the cross axis, that flex item no longer necessarily requires the
hypothetical main size that we originally gave it, so it's left with
some empty vertical space -- in Gecko, at least, which AFAICT is the
only engine following the spec on this point.)

So: I'm suggesting we address this by computing & enforcing stretched
cross-sizes earlier (in my original post on this thread). But as
dbaron points out, we could also address it by changing the intrinsic
width definition for flex containers such that they actually end up
being able to satisfy their children's intrinsic widths. (That's
probably tricky, though, and might require doing something equivalent
to the "resolving the flexible lengths" algorithm during
intrinsic-sizing.)

~Daniel

Received on Wednesday, 21 August 2013 19:02:27 UTC