Re: [css-flexbox] New "Resolving Flexible Lengths" algorithm disagrees w/ old algorithm, when we go from negative free space to positive free space (even with flexibilities >= 1)

On Thu, Apr 24, 2014 at 1:42 PM, Daniel Holbert <dholbert@mozilla.com> wrote:
> On 04/22/2014 04:38 PM, Daniel Holbert wrote:
>> To handle cases like this, I suspect we'd need to allow the algorithm to
>> recompute the items' "originally desired free space" values during the
>> loop, under some restricted conditions (including "when the free space
>> changes sign").  Or something like that.
>
> I think the best fix for this issue is probably to defer computing any
> "originally desired free space" values until the first time that the
> sign of our free space matches the flex-factor that we're using. (so, if
> we're using flex-grow, we hold off on computing "originally desired free
> space" values until we have a positive free space. Or if we're using
> flex-shrink, we wait until the free space is negative.)
[snip]

Just for closure, this email was addressed by our revival of the "CR"
algorithm, which is back to being based just on flex factors.

~TJ

Received on Tuesday, 1 July 2014 18:03:20 UTC