W3C home > Mailing lists > Public > www-style@w3.org > February 2015

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

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Mon, 23 Feb 2015 23:38:43 +0000
To: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, Rossen Atanassov <Rossen.Atanassov@microsoft.com>
Message-ID: <BY2PR03MB12888C6EE701BE081F419D2B4290@BY2PR03MB128.namprd03.prod.outlook.com>
We went back and forth on whether max-width is applied once to the final result or if it is also honored when calculating hypothetical main size. March 2012 draft had max-size explicitly excluded from hypothetical size calculation (that's what I implemented in IE10). June 2012 draft and current spec have it affect hypothetical size.

In my personal opinion, using same constraint for more than one purpose make it less useful. I was no longer in the group when it changed though.

Per current spec, Crome behavior is correct - max-width applies to both hypothetical size and used size.

-----Original Message-----
From: fantasai [mailto:fantasai.lists@inkedblade.net] 
Sent: Friday, February 20, 2015 5:51 PM
To: www-style@w3.org; Rossen Atanassov; Alex Mogilevsky
Subject: 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 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.
> 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.)
> 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.

Received on Monday, 23 February 2015 23:39:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:51 UTC