- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 5 Feb 2014 13:42:38 -0800
- To: Daniel Holbert <dholbert@mozilla.com>
- Cc: www-style <www-style@w3.org>
On Thu, Jan 30, 2014 at 3:15 PM, Daniel Holbert <dholbert@mozilla.com> wrote: > Hi Tab, > > I've got two more clarification questions on the new "Resolving Flexible > Lengths" text: > > 1) In the new "Resolving Flexible Lengths" text, the Loop has several > mentions of "all the flex items" or "each item" -- I think those all > want to be specifically about *non-frozen* items. I don't think we want > to apply those operations (e.g. summing desired sizes, clamping to > min/max range) on frozen items (since desired sizes are no longer > relevant, and we've already clamped). > > So: I think every mention of "items" or "each item" in the Loop steps > 3, 4, and 5 might want to be replaced with "non-frozen item[s]". Good point. Done. > 2) Right now, the "free space" is set once, before the Loop, and then > never updated. I think this is problematic. For example -- at the end of > the first Loop iteration, we may discover a min-violation and freeze a > flex item at a larger size (effectively eating up some, maybe all, of > the free space) -- but then on the next Loop iteration, the algorithm > doesn't account for that free-space-reduction. We'll still try to > distribute all of the original free space among the remaining > (un-frozen) items, and we'll end up sizing things too big. > > So: I suspect we might want to be recalculating the free space at the > end of each loop iteration, or something like that... Ah, you're right. I was remembering that we don't want to recalculate the *desired free space* (I have some examples that show why that's bad, if you need), but forgot that we still need to recalc the actual free space. Done. ~TJ
Received on Wednesday, 5 February 2014 21:43:47 UTC