Re: [CSS3] Flexible Flow Module, proposal.

Robert O'Callahan wrote:
> On Sat, Apr 11, 2009 at 8:49 AM, Andrew Fedoniouk 
> <news@terrainformatica.com <mailto:news@terrainformatica.com>> wrote:
> 
>     Here is our proposal for the new module named Flexible Flow:
> 
>     http://www.terrainformatica.com/w3/flex-layout/flex-layout.htm
> 
>  
> I quite like it.
> 
> As well as adding text to make it clear that 'float' does not apply to 
> flow children, you should also mention that 'clear' is not relevant when 
> flow is not 'default' or 'horizontal-flow' or 'vertical-flow'.

Thanks, makes sense indeed.

> 
> Actually, one thing I don't like is the way 'flow' mutates a block into 
> something that's really quite different. It would feel better to me if 
> there were new 'display' values, say 'flow' and 'inline-flow', and 
> 'flow' only applies when one of those is set. You wouldn't need 
> 'flow:default'.

De facto 'flow' declares all its immediate children to have something
like:
   block-formatting-context:true;

That [hypothetical] attribute is implied on floats, absolutely 
positioned elements, inline-blocks, table-cells, table-captions and 
elements with 'overflow'.

I do not think that it will cause any problems in implementation or
understanding by web authors.

If to introduce display:in-flow; then it will have following implications:
1) what if some child of flow-container has no display:in-flow
2) what if such a child needs to have display:table

and so on.

Intention was and is to have 'flow' as orthogonal to the 'display'
as possible.

> 
> Regarding naming, the property 'flow:horizontal-flow' uses the word 
> 'flow' in two different ways. Maybe 'horizontal-wrap' would be a better 
> term.

Yeah, probably.

> 
> You don't explicitly mention the order in which flow children are placed 
> (top to bottom, bottom to top, left to right, right to left). XUL 
> flexboxes let authors control this, and you probably should too, maybe 
> via additional flow values?

Oh, I've forgot to mentioned that.

Attribute 'direction' as it states defines direction for the 'flow' too.

Thus

   flow:horizontal;
   direction:rtl;

will replace elements in RTL order.

Support of direction:rtl; in the 'flow' actually was requested
by users from Middle East.


> 
> There seems to be no way to set the width of a flow child to the 
> intrinsic width plus some flex (or a specified width plus some flex). 
> That seems like a big limitation. In some cases you can use flex padding 
> or margins to get the effect, but sometimes you want the element to be 
> able to lay out its children in the extra width. Is there an easy way to 
> fix that?

Actually there is a question about that in the document.

I think it makes sense to introduce in this module values
'min-intrinsic','max-intrinsic' and 'intrinsic' for
[min/max-]width, [min/max-]height attributes. They proposed
once by David Baron but are really make sense in context of
the 'flow' and flexes only.

> 
> I don't understand this:
>  > All non-bound children of the templated container are appended to the 
> grid as if they span
>  > a single row in it.

You have a grid defined by the template:
flow: "a b"
       "c d"
Elements that have float:"a",etc. go to designated cells.
All children elements that have no name of the cell defined
simply appended to the grid as if they have float:"x", float:"y", etc.
defined and the template is defined as:

flow: "a b"
       "c d"
       "x x"
       "y y"
       "z z"
       ....


> You haven't said anything about how the template is actually laid out. 

It is laid out as a table. Rules are exactly the same. The only 
difference is that flow knows about flexes. So if say element
"c" has height defined as '1*' that row will flex (expand) taking all 
available space in the container shifting the rest to the bottom of
the container.

If it would be an interest to the spec I'll provide precise rules.

> You introduce the '*' unit without really defining it.. This seems like 
> the weakest part of your proposal, does it really need to be integrated 
> here?

Yes, flex units make sense not only in context of the 'flow'. E.g.
attempt to reproduce <table> layout in CSS requires display:table
use them too.

But for the legacy reasons I would keep flexes applicable to the flow'ed
containers only. With the only exceptions about position:absolute | 
fixed and inline-block elements where they too have a great value.

Flex units per se are not something new. They defined in HTML4 spec 
[1,2] where they used in <table>s and <frameset> definitions.

[1] http://www.w3.org/TR/html4/types.html#type-length
[2] http://www.w3.org/TR/html4/struct/tables.html#h-11.2.4.4
[3] http://www.w3.org/TR/html4/sgml/loosedtd.html#MultiLength

And what do you think needs to be added in "2. Flex length units"
section of http://www.terrainformatica.com/w3/flex-layout/flex-layout.htm
to define them better?


> 
> Rob
> -- 
> "He was pierced for our transgressions, he was crushed for our 
> iniquities; the punishment that brought us peace was upon him, and by 
> his wounds we are healed. We all, like sheep, have gone astray, each of 
> us has turned to his own way; and the LORD has laid on him the iniquity 
> of us all." [Isaiah 53:5-6]


-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Saturday, 11 April 2009 19:20:30 UTC