- From: Daniel Holbert <dholbert@mozilla.com>
- Date: Mon, 21 Apr 2014 19:57:59 -0700
- To: www-style list <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>

On 04/18/2014 02:54 PM, Daniel Holbert wrote: > After some thought, I *think* the old algorithm can be changed to > produce the same results as the new one if we simply insert a "step > 4.5", as follows: > > # Step 4.5: Adjust Free Space > # Compute the sum of the unfrozen flex items' flex factors. > # If this sum is less than 1, then multiply the free space > # by this sum (reducing the magnitude of the free space). > > In other words: if our flex items have flex-grow values that sum up to > 0.5, then this makes us only distribute 50% of the free space. Ah, it's of course not quite as simple as I thought. I've realized that my suggested old-algorithm-tweak doesn't quite match the New Algorithm in cases with max-violations. (but I think it's fixable) e.g. if we have 100px of free space, and two flex items with item1: "flex: 0.2" item2: "flex: 0.5; max-width: 10px" (triggering max-violation clamping for item2), then Tab's new Algorithm would give 20px to the first item (which makes sense), whereas the tweaked Old Algorithm (with step 4.5, quoted above) would only give 18px to the first item. This happens because we recompute the free space as being smaller (90px instead of 100px) on the second time through the loop, and then multiply 0.2 * 90px = 18px as being the space that we have for distribution when we determine the final size for that first item. HOWEVER, I suspect I can fix my "Step 4.5" spec-text to avoid this issue -- something like the following: # Step 4.5: Adjust Free Space # Compute the sum of the unfrozen flex items' flex factors. # If this sum is less than 1, compute the product of this sum # and the "original free space". If this product's sign matches # the free space's sign, and product's absolute value is less # than the free space's absolute value, then set the free space # to this product. (where "original free space" is the free space that's computed on the first time through the loop.) (The product that's computed here is basically the unfrozen items' total desired portion of the *original* free space. The idea is just to make sure we don't let them flex any more than that amount. The new algorithm does something similar.) I'm not 100% sure that this is complete, and I'm not suggesting making any spec modifications at this point. Mostly just posting to amend my earlier post. ~Daniel

Received on Tuesday, 22 April 2014 02:58:31 UTC