Re: [CSS3] Flexible Flow Module, proposal.

Seems like the message did not go through first time so I am repeating 
it again.


Tab Atkins Jr. wrote:
 > Initial comments
 > ================
 >
 > Differences between default and vertical flow
 > ---------------------------------------------
 > I think it would be worth emphasizing that:
 >
 > 1. Flex units can *not* be used within a flow:default container.
 > 2. Margins of a flow:vertical container do *not* collapse with the
 > container's children (a flow:vertical element establishes a BFC).

Thanks, I'll update the document.

 >
 > The first seems to be implied, but not outright stated.  The second is
 > stated later in the proposal, but should be repeated here to highlight
 > the differences between flow:default and flow:vertical.

Yes.

 >
 >
 > Margin Collapsing between two flex margins
 > ------------------------------------------
 > The spec doesn't specify this, but I assume that if two elements
 > within an appropriate container had abutting margins of 1* and 2*,
 > that they would collapse to form a single 2* margin?

Correct, that works as usual - maximum value is used.
The only difference as I mentioned is when flex margin is
collapsed with non-flex margin. The latter one is used as min
constraint when computing flexes.

 >
 >
 > Interaction of flexes less than and greater than one
 > ----------------------------------------------------
 > If you have two elements with widths .5* and 1* in a flow:horizontal
 > container, does this work identically to if the elements had widths 1*
 > and 2*?  It seems like the special free-space distribution mode only
 > triggers when the *sum* of the flexes is less than 1*, correct?

Yes, it works identically. Flexes are weights and soon as total sum is
greater or equal to 1*. So these two: 0.5*/1* and 1*/2* are identical.

That special mode is simple: computation of flexes uses 1* value
as a cap:
    used-total-flexes = max(total-flexes-seen, 1*);

That for example allows to move block in the middle of the viewport by
defining only left and top values:

#in-the-middle
{
   position: fixed;
   left: 0.5*;
   top: 0.5*;
}
or
#static-in-the-middle
{
   margin-left: 0.5*;
   margin-top: 0.5*;
}
for the static element that is the only child of its parent.
 >
 >
 > Clear and row/col wrapping
 > --------------------------
 > The spec is slightly unclear on this.  Does *any* value of clear other
 > than "none" automatically wrap the row?  Is the element that has the
 > clear property the one that goes down to the new row?  Overall I'd
 > prefer a new value for clear, such as "flow".  Using right in
 > horizontal flow doesn't make sense (assuming normal ltr direction),
 > and none of the values make sense for vertical flow.

clear:left|right here works as break:before|after.

Thus this:

ul { flow:horizontal-flow; }
ul > li:nth-child(3n) { clear:right; }

will replace li's in rows where each row will contain
3 elements.

And this:
ul > li:nth-child(3n) { clear:left; }
will make first row of two elements.

 >
 >
 > Effects of width:auto on children of a flow:vertical-flow element
 > -----------------------------------------------------------------
 > Is it ever possible to create a new column in a flow:vertical-flow
 > element if the children are all display:block and width:auto?  Their
 > width would fill the element completely.  What if their width was 1*?

In principle for all flows width:auto simply means width:1*;
The same is for margin:auto. It is simply margin:1*;

width:1* (as other horizontal flexes)
for elements in flow:vertical-flow is computed against column width
that is widest element in the column.

For column width computations I am using the following:
in-column-width = if( declared-width is flex-or-auto )
                     min( container-width, max-intrinsic-width);
                   else
                     declared-width;

flow:vertical-flow makes sense for top-to-bottom writings, e.g.
for East Asian scripts. It also makes sense if you want to see
<option>'s in <select> replaced as in list views in most desktop
list widgets.

 >
 > What happens if a child is wide enough to fill the entire containing
 > block, but you still have a forced break opportunity (either an
 > element with clear set, or an element which would cause the sum of the
 > vertical flexes to exceed 1*)?

That is not clear.

Row/Column shall have at least on element. Is this the answer?

 >
 >
 > Margin Collapsing Between Grandchildren of a non-default flowed element
 > -----------------------------------------------------------------------
 > You state that the children of a flowed element establish BFCs.  So,
 > given this structure:
 >
 > <ul style="flow:vertical">
 >   <li>
 >     <p>foo</p>
 >   </li>
 >   <li>
 >     <p>bar</p>
 >   </li>
 > </ul>
 >
 > The two paragraphs do *not* collapse their margins across the <li>
 > boundaries, correct?  So we are guaranteed (assuming standard
 > defaults) a 2em separation between the "foo" and the "bar", right?

Yes. If li's have no margin and p's have margin-top/bottom:1em;

 >
 >
 > position:absolute on a child of a non-default flow element
 > ----------------------------------------------------------
 > You seem to say (in section 5) that abspos and fixedpos is *not
 > allowed* on children of an element with non-default flow.  Is this
 > correct?  If so, why?  Can't abspos/fixedpos elements just be removed
 > from the flow like normal, so they don't contribute to the flex
 > calculations?


In fact in my current implementation position:absolute|fixed work
as usual - excluded from the flow and replaced as usual for positioned
elements. Technically it is feasible. But may conflict with particular
implementation when, say, top or left are 'auto'. Another suspicious
area is flow:"template". I am not sure what, let's say, position:fixed
for its child should mean.

But yes, in general this limitation can be relaxed.

 >
 >
 > Flex units and float
 > --------------------
 > How does a floated child of a non-default flow container interact with
 > the other children?

It does not interact as float:left|right is simply ignored for immediate 
children of the flow container. floats inside flowed elements are OK 
(replaced in the same way as in table cells).

(I have to mention this in the document.)


 >
 >
 > Children of a flow:template container without an appropriate position 
property
 > 
------------------------------------------------------------------------------
 > Are they merely appended to the bottom of the container?  The spec
 > just indicates that they take up a single full row in the container.

They simply extend the grid by appending anonymous rows defined ones.

So if you have

ul { flow: "a b"; }
li:first-child { float:"a"; }
li:last-child { float:"b"; }

and markup:

<ul>
   <li>First</li>
   <li>Second</li>
   <li>Last</li>
</ul>

then it will be replaced as:

+-------+------+
| First | Last |
+-------+------+
|   Second     |
+--------------+

That is very simple schema that does not require artificial block
containers to be created. That phantom block containers will require
pseudo-elements,etc. - not good at all.

 >
 >
 > ~TJ
 >
 >


-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Saturday, 11 April 2009 21:08:23 UTC