- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 20 Feb 2015 20:50:52 -0500
- To: www-style@w3.org, Rossen Atanassov <Rossen.Atanassov@microsoft.com>, Alex Mogilevsky <alexmog@microsoft.com>
On 02/17/2015 11:28 PM, Daniel Holbert wrote in https://lists.w3.org/Archives/Public/www-style/2015Feb/0377.html > 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? 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. Rossen/Alex? ~fantasai
Received on Saturday, 21 February 2015 01:51:22 UTC