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

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 31 Aug 2015 23:23:18 +0200
To: www-style@w3.org
Message-ID: <55E4C5C6.6070806@inkedblade.net>
On 08/25/2015 03:42 AM, Christian Biesinger wrote:
> Thanks for updating the spec. That makes things clearer/make more
> sense. However, I have a couple of concerns:
> - I believe as worded right now, the text does cause a division by
> zero in case the flex grow factor is 0, as the minimum of 1 is now
> removed

I don't think so, because if the grow factor is zero, the max-content
contribution gets clamped at the flex base size, and the result of
the first calculation will be zero. Right?

> - I haven't traced the algorithm but just wanted to make sure that you
> took into the account flex factors that sum to less than one (e.g.
> flex: 0.8 + flex: 0.9)

The numbers you mention sum to less than one, but in any case we think
this should give results consistent with the way the flex algorithm
handles such numbers. If that's not the case, let us know...

> - I sort of wish the spec was more explicit that vertical sizing of a
> flex container is different from all other display types in that it
> follows the intrinsic sizing rules

Added some introductory text:

Let me know if that's good, or if you have any suggestions for improvement. :)

> - Most importantly, I feel like it's way too late to change the 0%
> back to 0 for the flex basis. Flexbox has been shipping in browsers
> for years. This does change what I think is a fairly basic property
> for the flexbox algorithm.

I think that the 0% change was a mistake that doesn't make sense in
the context of a correct implementation of this section. I also it's
unlikely that someone would use the flex: <integer> shorthand syntax
in an auto-height container (which is where this change will make a
difference), since it doesn't do anything more than the initial value.

> - On a similar note, has the CSSWG made any attempts to see how
> compatible the intrinsic size changes are, especially for column
> flexboxes?

No, I don't think we have. Wrt column flexboxes, I suspect it's unlikely
to make a difference since there's no reason to use values other than
the initial value unless you want different behavior than you're getting

I'll bring up your email for discussion with the other editors, though.

Received on Monday, 31 August 2015 21:23:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 31 August 2015 21:23:51 UTC