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

"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 UTC