Re: [css-flexbox] max-content contribution not defined for flex items

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

Received on Friday, 21 August 2015 07:21:10 UTC