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 12:46:31 -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: <20100530124631.5752d482@moxana.local>
"Andrew Fedoniouk" <news@terrainformatica.com> wrote:

> There is no concept of "likely works" or "likely does not work" in
> CSS, sorry.
> 
> 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.

What about specifying that the preferred width of a calc() that
evaluates to a flexible length is the inflexible component?  Then there
is no discontinuity, the preferred width of calc(100px + αfx) is 100px
regardless of the value of α.

> As of throwing the babies...
> I've proposed simple function:
> flex( <length-expression>, flex-weight ).
> where length-expression can be literal fixed length or the calc()
> 
> What is the problem with it?

You are mistaken in thinking that calc() involving flex units is
somehow harder to implement than that notation.  Your flex(α, β)
(where α is any <length> and β is a number) is precisely equivalent 
to calc(α + βfx), as far as I understand.  An arbitrary calc()
expression involving flex units can either be algebraically reduced
to calc(α + βfx) at parse time, or it can't.  Those that can't, we
simply define as semantic errors.  Thus, calc() involving flex units
requires no more cleverness at layout time than your flex() does; and
the algebraic reduction code is already present in the calc() parser,
because it has to reject things like width: calc(10%/10px) already.

zw
Received on Sunday, 30 May 2010 19:47:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:27 GMT