W3C home > Mailing lists > Public > www-style@w3.org > July 2014

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)

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 1 Jul 2014 11:02:33 -0700
Message-ID: <CAAWBYDAEFOSeB2gbM3XknYdmCCs0L=+ZWTOV1Xs30QzXxrG7fg@mail.gmail.com>
To: Daniel Holbert <dholbert@mozilla.com>
Cc: www-style <www-style@w3.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC