W3C home > Mailing lists > Public > www-style@w3.org > May 2010

Re: [css3-flex] calc(flex) and concept of free space.

From: Zack Weinberg <zweinberg@mozilla.com>
Date: Sun, 30 May 2010 14:49:34 -0700
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "Brad Kemper" <brad.kemper@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, <www-style@w3.org>
Message-ID: <20100530144934.690275f0@moxana.local>
"Andrew Fedoniouk" <news@terrainformatica.com> wrote:

> >> Both of these two expressions:
> >> width: calc(100px + 0.0001fx)
> >> width: calc(100px + 0.01fx)
> >> *must* produce close or the same result.
> >> But not 0px and 100px.
> >
> > I more or less agree with this, although I don't think it's a
> > *critical* problem; people are used to the occasional floating-point
> > glitch.
> Sorry, is this about Gecko or in general ? :)

In general.  Floating point has sharp edges.

> Expressions like
>  width: calc(100px + 1fx)
> participate in flex calculations twice:
> First time to determine free space and second time when
> free space is known and so we can do that final widths calculations
> with respect of flexes and that preferred width.

Sure.  All I'm saying is that the problem here could be resolved if the
width used for the first pass was a rigid 100px.  Which I guess is what
you are also saying, but it's hard to tell.

Also, to be clear, I am not interpreting Tab's spec.  I am saying what
I think should happen, and I am not paying attention to previous specs
or implementations.

> I have implementation of the calc() and flex units already.
> I am trying to implement calc() with flexes so are my questions.

I understood your objection to calc() with flexes to be based on the
hazards of arbitrarily complex algebraic expressions with a flex unit
buried somewhere in there, and it is this problem that I say can be
resolved as I described.

Any objection to calc() with flexes that is *not* based on that hazard
is surely just as applicable to your flex(base-length, flex-strength)

> There would be no problem at all if all this would follow
> prof. Knuth logic (TeX) and so
> width: calc(100px + αfx) for the need of
> free space calculations always evaluates to
> 100px. But that would simply mean that result of
> calc(100px + αfx) is always >= 100px and so there
> is no such thing as "negative free space".

I agree that negative flex is undesirable unless explicitly
asked for (as I said elsewhere) but I do not see that it poses a
*technical* problem, only a comprehensibility problem.  In this
specific case, making calc(100px + αfx) evaluate to 100px for free
space calculations does *not* imply that it is subsequently forced to
be at least 100px, as far as I can see.

Received on Sunday, 30 May 2010 21:50:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:46 UTC