- From: Daniel Holbert <dholbert@mozilla.com>
- Date: Thu, 17 Apr 2014 14:34:12 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: www-style list <www-style@w3.org>

Hi Tab, So, I've got a patch that implements the new resolving-flexible-lengths algorithm pretty much directly from the spec text -- but, in sorting through edge cases with float accumulation error & very large flex values that I'd previously accommodated in my impl of the old algorithm, I'm wondering whether it'd be better for me to just tweak my implementation of the old algorithm instead of entirely replacing it. Given that you opted to rewrite the algorithm in the spec completely (rather than just tweaking it), I'm curious whether you think this is doable/wise. I suspect it should be, based on this comment: On 10/09/2013 10:59 AM, Tab Atkins Jr. wrote: > This [new] algorithm should be identical to the current flexing algorithm > when all the items have a flex of 1+, or when the non-violating items > in the final cycle have a sum of flexes 1+. Assuming that this comment still holds, am I correct in thinking that the old algorithm could be tweaked to match the new algorithm simply by making some simple modifications to old-step-5 ("Distribute free space proportional to the flex factors")[1]? The following modifications in particular: - If we're using flex-grow, and the sum of flex-grow factors is < 1, then use the flex-grow factor directly. - If we're using flex-shrink, and the sum of flex-shrink factors is < 1, then renormalize the scaled flex shrink factors so that their total is equal to the sum of [unscaled] flex-shrink factors, and use these renormalized values directly. (When I say to use a factor "directly", I mean "multiply that factor by the available free space, and claim that much free space".) Thanks! ~Daniel [1] old algorithm is available e.g here: http://www.w3.org/TR/2012/CR-css3-flexbox-20120918/#resolve-flexible-lengths

Received on Thursday, 17 April 2014 21:34:43 UTC