Re: [css-flexbox] Should "max-width" influence the resolved flex base size? (from default "flex-basis:auto;width:auto")

On 02/17/2015 11:28 PM, Daniel Holbert wrote in
> Consider the following jsfiddle:
> It has two flex items, which are forced to shrink. The first item
> (purple) has "max-width: 80px", and has a child that is very wide
> (500px).  The second item (orange) just has "width: 80px".  Their
> container is only 100px wide, so they don't fit, and we shrink them with
> the flex layout algorithm.
> QUESTION: What is the first flex item's "flex base size" -- is it 80px,
> or 500px? Specifically, does its "max-width" impact how its contents are
> measured, to establish its flex base size?
> This dramatically affects the rendering -- if its flex base size is 80px
> (from 'max-width'), then the two items will shrink from the same
> starting-point and will end up at the same final width of 50px. BUT, if
> its flex base size is 500px, then it starts shrinking from that
> much-larger value, and ends up being clamped & frozen at its max-width
> (80px) later in the algorithm. And then the other flex item is forced to
> shrink to 20px.
> Firefox/Gecko *ignores* max-width when resolving the flex base size from
> the flex item's contents. So, Firefox renders the first item as being
> wider than the second (because we start shrinking the first item from a
> larger starting-point, and clamp to max-width during the flex layout alg.)
> Chrome/Blink *honors* "max-width" when resolving the flex base size --
> so it ends up with both flex items shrinking from 80px and having an
> equal final size of 50px.
> I'm not sure which is correct. (see discussion below)  (I'm also not
> sure what other engines do; IE11 has a strange behavior where it refuses
> to shrink my first flex item below 500px at all, so it ends up very
> wide. And I haven't tested Edge/Spartan.)
> I believe this behavior is governed by spec section 9.2, step 3, part E
> ("Determine the flex base size and hypothetical main size
> of each item:").  This section doesn't say anything explicit about
> suppressing the max main size property when laying out the flex item, so
> that suggests that Chrome is correct. However, the sentence right after
> this section defines the "hypothetical main size" as being the flex base
> size, "clamped according to its min and max main size properties."  This
> suggests (weakly perhaps) that these min/max properties should not have
> been applied when resolving the flex base size.
> I also recall an earlier version of the spec being more explicit about
> the min/max main size properties being *ignored* until the algorithm
> *explicitly* considers them. (This is why Gecko does what it does.) I
> wonder if that language was lost accidentally?

I think it was accidental. Given we have conflicting behavior here,
though, it might be good to check that the spec's behavior is indeed
the one we want. I haven't really thought through the use cases.


Received on Saturday, 21 February 2015 01:51:22 UTC