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.)

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

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:44 UTC