- 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