- From: Daniel Holbert <dholbert@mozilla.com>
- Date: Tue, 17 Feb 2015 20:28:16 -0800
- To: www-style list <www-style@w3.org>
Consider the following jsfiddle: http://jsfiddle.net/jL7t19nd/1/ 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. BROWSER DISAGREEMENT: 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.) SPEC REFERENCE/DISCUSSION: http://dev.w3.org/csswg/css-flexbox-1/#flex-base-size 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? Thanks, ~Daniel
Received on Wednesday, 18 February 2015 04:28:47 UTC