Re: [css3-flexbox] Bad result in flex algorithm when combining stretch, and elements with an aspect ratio

Could you explain first what that "align-self=stretch"
means exactly ?

As far as I understand it is sort of this

img {
   width:*; // flex width
   max-width:max-content;
   height:auto; // calc( used-width * intrinsic-ratio)
}
so it will take all available width but not more than
intrinsic image width. Therefore the image is always
inscribed into horizontal free space of its container.

If UA is not capable of flexes inside line-box
context then this can be somehow modeled by

img {
   width:100%;
   max-width:max-content;
   box-sizing:margin-box; /*note: there is no such
                                       thing as margin-box*/
   height:auto;
}

In both cases there are no problems with flex calculations.
The only thing - auto-stretch images should have flex:1 as
a side effect.

And if that "align-self=stretch" means that
it can arbitrary reduce width while setting height then
this creates conditions for oscillations in layout algorithm.
Not only for flex containers but for standard text/line-box
algorithms. So UA shall fix this one way or another.

So we need to know what that align-self=stretch means
before fixing anything.

-- 
Andrew Fedoniouk.

http://terrainformatica.com



On Sun, Oct 28, 2012 at 8:51 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> Rossen pointed out a problem with the flexbox layout algorithm in the
> following situation:
>
> <flexbox direction=row height=100px width=500px>
>   <image intrinsic-width=100px intrinsic-height=200px align-self=stretch />
>   <div flex=1 />
> </flexbox>
>
> So, run the layout algorithm:
>
> * In step 3, the image is set to 100px wide and the div to 500px wide.
> * In step 6, the div is flexed to 400px wide.
> * In step 9, the image is stretched to 100px tall, which also shrinks
> its width to 50px, due to its aspect ratio.
>
> We now have underflow in the main axis (container is 500px wide,
> content fills 450px), even though there was a flexible item!  This is
> clearly nonsense.  (If the ratio was the other way around, you can
> similarly get overflow.)
>
> You get similar issues with multiline flexboxes, where 'stretch' can
> cause a line to be under/overfilled.
>
> The obvious solution here is to move 'stretch' resolution up, to
> before the current line-breaking and flexing steps.  I don't think
> this is too controversial - aside from this special case, the
> difference is undetectable.
>
> However, that brings up a further problem.  If you *first* stretch,
> but the item is also flexible, the flexing can cause it to no longer
> fill the flex line.  In other words, it might simply be impossible to
> simultaneously honor the aspect ratio, the 'stretch' keyword, and a
> non-zero "flex" value.  This is similar to how you can't always
> simultaneously honor width, height, and the aspect ratio.  We satisfy
> the latter by breaking the ratio; we consider an explicit width and
> height to be stronger than the implicit aspect ratio.
>
> We should do the same here.  While the width and height aren't
> explicit in the usual sense, they are determined by strong external
> constraints, which fill a similar role.  So, in the presence of both
> constraints, we should ignore the aspect ratio, and simply make the
> element honor the "stretch" and 'flex' constraints.
>
> Any objections?  Otherwise, I'll edit the flexbox layout algorithm
> with the following two changes:
>
> 1. Add a bullet point to step 3 (hypothetical main size determination)
> to handle aspect-ratio items with "stretch" alignment (so they get the
> correct hypothetical main size).
> 2. Modify step 9 (handling "stretch" alignment) to have an explicit
> statement about handling aspect-ratio items, to clarify that it
> changes the cross-size *while ignoring the aspect ratio*, so the main
> size doesn't change.
>
> ~TJ
>

Received on Sunday, 28 October 2012 17:31:12 UTC