W3C home > Mailing lists > Public > www-style@w3.org > May 2010

Re: Box Reordering

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Mon, 24 May 2010 17:56:08 -0700
Message-ID: <88DECB0A52CA4A3F9FF0D86B99E64D4B@terra3>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, "www-style list" <www-style@w3.org>


--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Monday, May 24, 2010 4:53 PM
To: "www-style list" <www-style@w3.org>
Subject: Box Reordering

> 
> .... Flex units are limited to
> flexbox children, because they don't work properly in normal flow (so
> far - I'm interested in seeing if we can do something reasonable with
> them later).  

Technically flex units can work in normal block and text flow.
Normal flow (in my case flow:auto) is using either default 
block or text flow - depends on actual content of the element. 

In [default] block flow you can use horizontal flexes without
restriction, their computation happens on initial layout pass. 
Vertical flexes are computed only when current context 
has no floats. That is very easy to achieve as vertical 
computation happens as a last step of layout - at this 
point you know have you floats or not. If no floats 
flexes can be computed.
Consequence of this rule: <body> can always use 
flexes: 
   body { margin: 8px; size: 1*;  } 
as it establishes top level BFC.

Subjects of [default] text flow are character glyphs and
inline-block/table elements  that are replaces inside
line boxes. So flexes in elements inside line boxes
can be computed against the line-box. So this:

<p>Sample:<input type="text" width:1* /></p>

makes sense - input will take rest of the space left
on the line from fixed "Sample:" brick.


> ... But does content-reordering cause any similar problems?

think about 'float', 'clear'... how they will play with content-reordering?
<span direction:rtl> and bidi in general is also worth to think about.
What about drawing order, z-index, etc?

-- 
Andrew Fedoniouk.

http://terrainformatica.com

 
Received on Tuesday, 25 May 2010 00:56:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:27 GMT