# [css3-flexbox] Algorithm never clamps inflexible children, when all children are inflexible

From: Daniel Holbert <dholbert@mozilla.com>
Date: Tue, 05 Jun 2012 17:35:53 -0700
Message-ID: <4FCEA5E9.3040905@mozilla.com>
To: www-style <www-style@w3.org>
```Right now, I don't think the spec's algorithm ever clamps inflexible
items to their min-max range, when all the children are inflexible.

As an example: suppose we have a flex container with 2 items, both of
which have w/ "flex: 0 0 10px" and "min-width: 50px".  Let's say the
flexbox has an explicit "width: 200px", for simplicity -- so there's
plenty of available space.

Clearly, we want our flex items to both end up with a main size (width)
of 50px.  But right now, that doesn't explicitly happen, AFAICT.

We'll hit the following steps in the algorithm:
# 9.2. Line Length Determination
#  2. Determine the hypothetical main size of each item:
#     If the item has a definite flex basis, that's
#     the hypothetical size.

--> hypothetical main size = 10px

# [...]
#  6. Resolve the flexible lengths of all the flex items
#     to find their used main size

--> OK, that takes us here:

# 9.7. Resolving Flexible Lengths
#  2. Check that you can distribute any space. If all the
#     flex items on the line are either frozen or have a
#     flexibility of zero, exit the algorithm.
#  [...]
#
--> All our flex items have a flexibility of 0.

So now we've exited the algorithm -- but it never actually set the used
main size of our items!!  The only main size we've actually set is the
"hypothetical main size", which is still at 10px (unclamped).

~Daniel

(NOTE: The algorithm does have us do some _temporary_ clamping in a few
places -- "Collect flex items into flex lines" and "Determine the used
flexibility" -- but that clamping is just for the purposes of those
steps, and its effects don't stick.  Section 9.2 also says to _not_
clamp flexible lengths at that point, but it doesn't definitively say
that we _should_ clamp inflexible lengths.)
```
Received on Wednesday, 6 June 2012 00:36:23 UTC

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