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

--------------------------------------------------
From: "Zack Weinberg" <zweinberg@mozilla.com>
Sent: Sunday, May 30, 2010 12:46 PM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "Brad Kemper" <brad.kemper@gmail.com>; "Tab Atkins Jr." 
<jackalmage@gmail.com>; <www-style@w3.org>
Subject: 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.

Sorry, is this about Gecko or in general ? :)

>
> 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 α.

Seems like you did not get the problem.

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.

Tab insist that for the div element

<div flow:horizontal width:1000px>
  <A width: calc(100px + 0.0001fx) />
  <B width: calc(100px + 0.01fx) />
</div>

free space will be 1000px - 100px = 900px;
because at this stage
width: calc(100px + 0.0001fx) evaluates to 100px ( as 0.0001fx = 0fx)
and width: calc(100px + 0.01fx) evaluates to 0px as ( as 0.01fx > 0fx) .

I am not getting the idea of such math.

>
>> 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.
>

I have implementation of the calc() and flex units already.
I am trying to implement calc() with flexes so are my questions.
E.g. length units in my case are numbers with fixed point (for many good 
reasons).
So 0.0001pt is effectively 0pt. With float numbers problem
is less severe but still depends on number of bits in float.

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

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Sunday, 30 May 2010 21:32:30 UTC