W3C home > Mailing lists > Public > www-style@w3.org > October 2013

Re: [css-flexbox] Fixing a mistake with flex-grow betwen 0 and 1

From: Daniel Holbert <dholbert@mozilla.com>
Date: Wed, 09 Oct 2013 07:55:59 -0700
Message-ID: <52556E7F.1060702@mozilla.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Fran├žois REMY <francois.remy.dev@outlook.com>
CC: www-style list <www-style@w3.org>
Sorry, it was apparently too late when I wrote my previous emails and I
hadn't thought it through well enough.

I've realized that the situation I brought up wouldn't cause the problem
that I was worried about - it should work pretty nicely, in fact.

[I do have a question about the spec edit, but I'll ask that in a
separate message]


On 10/08/2013 11:31 PM, Daniel Holbert wrote:
> Superficially, this strikes me as a reasonable change, though the
> interaction with max-size in situations like what you described is
> interesting...
> Even in cases where rounding behavior doesn't come into play, there'd be
> potential for weird discontinuities (much like the original
> discontinuity at 0 that you're trying to avoid).
> Consider a case with:
>  <flexbox>
>    <div style="flex: 0.2; width: 5px;"></div>
>    <div style="flex: 0.2; width: 5px; max-width: 5px"></div>
>  </flexbox>
> There, we'd give 20% of the free space to the first flex item, and no
> free space to the second item (due to its max-width).
> Now, if we increase the "flex" on the second item to 1 (still not
> affecting *its* rendering at all due to its max-width), then all of a
> sudden the *first* item will snap up to occupy all of the free space,
> because our flex values sum to more than 1.
> I'd like to avoid that sort of discontinuity, if possible, because IIUC
> this tweak is trying to prevent that sort of thing, when really it just
> makes it somewhat harder to trigger. (which doesn't feel satisfying)
> ~Daniel
> On 10/08/2013 09:31 AM, Tab Atkins Jr. wrote:
>> On Tue, Oct 8, 2013 at 3:12 AM, Fran├žois REMY
>> <francois.remy.dev@outlook.com> wrote:
>>> That being said, it still exposes browser rounding when
>>> computing whether the sum is equal or greater than 1.
>>> It is likely than to defeat rounding issues UA will want to
>>> accept a certain "snapping-to-1" tolerance.
>> It'll only expose rounding when there are min/max violations - if two
>> items both have "flex: .49;" and one has a small max-width, the other
>> will still only fill half the free space, while if they both had
>> "flex: .51;", the other would fill all the remaining space.
>> I'll think on this a bit more - there may be a way to hide this as well.
>> (If I can't, then browsers are of course free to implement "rounding"
>> as they see fit - it's undefined, so having a bit of tolerance is
>> totally possible.)
>> ~TJ
Received on Wednesday, 9 October 2013 14:56:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:03 UTC