On 07/28/2015 01:21 PM, fantasai wrote:
> The spec currently defines the max-content contribution of a flex
> item as its hypothetical base size. However, I don't think this
> works correctly for flexible items with a definite flex base size.
> In particular, notice
> # For each flex item, subtract its flex base size from its
> # max-content contribution size,
> This calculation will end up at zero for items with "flex: 1",
> when the intention was for it to tend up at the max-content size.
>
> Proposed definition:
>
> | The max-content main-size contribution of a flex item is:
> | * if the item is growable, max(max-content, flex base size)
> | * otherwise, its flex base size
> | clamped by its min and max main size properties.
>
> Together with the definition of the max-content size of flex containers [1],
> I think this will give the expected results (no unnecessary wrapping
> of shrinkwrapped flexboxes, no unnecessary or unrequested extra space).
> https://drafts.csswg.org/css-flexbox-1/#intrinsic-sizes
Okay, I went over this section with dholbert today, and we've
concluded that the spec needs the following changes:
1. Define the min-content and max-content contributions of a
flex *item* to be its min/max-content size, clamped as
appropriate.
[ As aforementioned, the spec references their "hypothetical
base size", which returns the min/max-content sizes when
the flex basis is 'content', but doesn't give correct
results (returns zero) in the the "flex: 1" case. ]
2. Clamp the flex items' min/max-content size contributions
not just by the min/max-width/height properties, but also,
if the item is inflexible in any direction, by its flex
base size.
[ For example, a shrinkable but not-growable item should
have its contribution also be min()ed against its flex
base size, not just its max-width/height. ]
3. Don't floor the flex factor at 1.
[ This might be left over prose from before we had partial
flexes. ]
4. Change "flex: 1" to expand to "1 1 0" instead of "1 1 0%",
[ We used 0% because in intrinsic size calculations it
would fall back to 'auto', but this is a hack that
a) doesn't give great results in many cases
b) breaks given a correct implementation of flex
container intrinsic sizing per spec
]
5. Make sure things are worded so we don't divide by zero. :)
Some examples to work through are two flex items:
* min-content = 1em, max-content = 2em
* min-content = 1em, max-content = 4em
with all combinations of:
* all items as flex: 1, flex: auto, or flex: 0.5
* min-content sizing or max-content sizing for the container
(We did this and they all made sense.)
The one thing up in the air is if the flex base size should
be considered a desired size, and therefore factored into
the intrinsic size calculation. dholbert was leaning towards
no, and considering the flex base size only as a starting
point for flexing. The original proposal in this thread would
do that:
| The max-content main-size contribution of a flex item is:
| * if the item is growable, max(max-content, flex base size)
| * otherwise, its flex base size
| clamped by its min and max main size properties.
by using the flex base size as a minimum for the items' intrinsic
sizes.
Alternatively we could do that only if 'flex-basis' is 'auto',
i.e. honor the width/height property (the main size property)
as a minimum if it happens to be used in the flex calculations
(as the flex base size). [ Using width/height unconditionally
yields nonsensical results, since it isn't otherwise factored
into the flex sizing calculations. ]
~fantasai