Re: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox Module

--------------------------------------------------
From: "Alex Mogilevsky" <alexmog@microsoft.com>
Sent: Thursday, May 13, 2010 8:32 PM
To: "Tab Atkins Jr." <jackalmage@gmail.com>; <robert@ocallahan.org>
Cc: "Adam Del Vecchio" <adam.delvecchio@go-techo.com>; <www-style@w3.org>
Subject: RE: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox 
Module

> What is the purpose of (1a)? If author wanted "1fl" instead of "auto" they 
> would have said so. Why make it a special case?

width:auto is getting resolved to different values in different layout 
systems. E.g. for the same
element in normal flow and when it floats its width:auto will lead to 
different values.
Flex layout system is not an exception regarding auto's.

Consider 3 blocks in horizontal flow.  Each block has width:auto (default 
value).
What would be you expectation about block widths? All of them should have 
the same
width. And that is exactly what happens as if they would have width:1*; 
(a.k.a. 1fl)
>
> (3) is different from current spec in how it treats negative extra space. 
> Is there evidence that current behavior is undesirable?
>

It is not clear what value to use as a "base value" in Additive Flexes.
See: http://lists.w3.org/Archives/Public/www-style/2010May/0209.html

It appears as nobody has clear understanding
of how this "base value" (or "preferred value") is computed.

As an example, what would be that base value for the case:
div { min-width:20px; width:10px; }
?

There is no evidence that Additive Flexes are required either.
If you have and idea where exactly Additive Flexes are useful then could
you share it?

> (4) should be unnecessary. If flex is allowed in padding (not that I agree 
> it is a good idea), it should be clearly stated which set of flexes it 
> belongs to. It should be either internal to Flexbox or external, not 
> conditional.

Flex values are all about computing dimensions inside some box.
Flexes in children are computed against content box of their container.

Therefore child element here:

container
{
   padding-top: 1*;
   height: 100px;
   flow: vertical; /* or whatever we will come up with */
}

child
{
   padding-top: 1*;
}

will be bottom aligned inside 100px content box of the container.

container's padding-top: 1*; is not participating in flex computation
of its children.

BTW: border-width in flexes also make sense in shed of light of
border-image and probably border-radius.

>
> It is not quite clear from the algorithm if it is moving from "additive" 
> flex to "absolute". It looks like it is absolute. Is it?

I hope it is about "absolute" flexes.
 "additive" flexes create  more problems than solutions.
Anyway no one have real proof of additive flex necessity so far...

-- 
Andrew Fedoniouk

http://terrainformatica.com


>
> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Thursday, May 13, 2010 5:56 PM
> To: robert@ocallahan.org
> Cc: Alex Mogilevsky; Adam Del Vecchio; www-style@w3.org
> Subject: Re: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox 
> Module
>
> Well, turns out the algorithm for calculating flexes is remarkably easy.
>
....

Received on Friday, 14 May 2010 10:59:09 UTC