Re: [CSS3] Flexible Flow Module, proposal.

On Sun, Apr 12, 2009 at 7:19 AM, Andrew Fedoniouk <news@terrainformatica.com
> wrote:

> Robert O'Callahan wrote:
>
>> 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


I'm not sure what you think the problem is. 'display' is not inherited.
Elements with various 'display' values behave in a parent with
'display:flow' much like they would in a parent with 'display:block'.

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


Well, it's not. In your proposal it only makes sense for elements that have
block layout inside, i.e. block, inline-block, list-item, table-cell, maybe
run-in (although it would feel very strange indeed when a run-in loses all
its 'flow' behaviour when it runs in).

I echo what others have already said: 'flow' is almost exactly the same as
'display-model', because it defines how an element lays out its children. I
had mixed feelings about 'display-model', in particular it seemed a bit
over-complicated, but I think your proposal actually helps justify that
complexity.

If people still feel that splitting 'display' into 'display-role' and
'display-model' is too much, then I still think you should go with
display:flow and display:inline-flow to avoid overloading blocks with quite
different behaviour.

Personally though, I think I'd rather move to 'display-role' and
'display-model' instead of having to define 'inline-flow',
'inline-template', etc, and other troubles around list-items and
table-cells.


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


You will probably want explicit control that does not depend on 'direction',
as well, especially for vertical flows.


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


That is not what I was asking for.

Suppose I have elements A and B with intrinsic widths 100px and 200px
respectively. Suppose the container has width 400px, and I want the extra
space to be distributed equally to A and B, so they end up with widths 150px
and 250px. Your proposal has no way to do this as far as I can tell, nor is
it possible by setting min-widths or max-widths.

This is actually the default behaviour for XUL boxes, so it seems important
to me that any flex-box-like spec be able to do it.

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.


Yes, that's very important.


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


I mean *templates* are the most underspecified part of your proposal and are
really orthogonal to the rest of it.


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


It should at least define what the value '*' (i.e., with no number) means,
if you're going to use it in examples.

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]