- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Mon, 24 May 2010 17:56:08 -0700
- 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 UTC