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

On Sun, May 30, 2010 at 11:40 AM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
>
> --------------------------------------------------
> From: "Brad Kemper" <brad.kemper@gmail.com>
> Sent: Sunday, May 30, 2010 10:39 AM
> To: "Andrew Fedoniouk" <news@terrainformatica.com>
> Cc: "Tab Atkins Jr." <jackalmage@gmail.com>; <www-style@w3.org>
> Subject: Re: [css3-flex] calc(flex) and concept of free space.
>
>>
>> On May 30, 2010, at 10:06 AM, Andrew Fedoniouk wrote:
>>
>>> So you are saying that this expression:
>>> width: calc(100px + 1px/100% * 1fx)
>>>
>>> may or may not participate in free space
>>> calculations.
>>> If  1px/100% is close to zero the expression will be calculated to "fixed
>>> 100px" and to be extracted from available free space. In all other cases it
>>> calculates to zero (for the need of free space calculation)
>>>
>>> This means that layout calculation is using unstable algorithm by design
>>> - mathematically speaking it has singular points on some widths.
>>> This will not fly, sorry.
>>
>> Your example is very contrived and extremely unlikely to occur for any
>> reason OTHER than to demonstrate precision differences between UAs. THat is
>> not reason enough to throw the baby out with the bathwater. In normal use,
>> you would never just one, near-zero flex measurement in a flexbox.
>>
>
> 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.
>
> 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?

As Zack said, there is absolutely no difference between calc(<length>
+ <flex>) and flex(<length>,<flex>).  The two are precisely identical;
they're just two different syntaxes.  For, surely, flex(100px,0fl)
should be the same as just "100px", right?

If so, then your syntax suffers from the exact same problem.

The essential issue is that the effect of a flex is relative to
surrounding flexes, not to some arbitrary "base" level.  If a flexbox
has two children with widths 1fl and 10fl, they should be the exact
same width as a flexbox who's children are 10,000,000fl and
100,000,000fl, or a flexbox who's children are .00000001fl and
.0000001fl.

That's not actually possible, though - to do so would require
implementations to use arbitrary-precision floating points, which is
far too slow to use.  So, at some point, an implementation is going to
fail and round a very small number to 0.  Oh well.  I'd be fine in an
impl rounded such lengths to some "epsilon" flex, just noting that
it's flexible, but to a degree that's too small to note.  That'd still
cause problems with relative width of flexible lengths (everything
small enough would be an epsilon, and thus equal), but it would at
least ensure that flexible lengths stayed flexible no matter how small
their flexibility is.  But I'm not going to go out of my way to
require that of an implementation, because the cases where that
becomes important are so far away from ordinary author behavior that I
don't care about them.  Authors are free to file bugs on browsers if
they have problems with the implementation.

~TJ

Received on Sunday, 30 May 2010 23:25:47 UTC