On Sun, Jun 8, 2008 at 9:46 AM, Andrew Fedoniouk <ne...@terrainformatica.com <mailto:ne...@terrainformatica.com>> wrote:

Consider following change (CSS 2.1):

9.4.1 Block formatting contexts

*Blocks in flex context,* floats, absolutely positioned elements, inline-blocks, table-cells, table-captions, and elements with 'overflow' other than 'visible' (except when that value has been propagated to the viewport) establish new block formatting contexts.

Where "block in flex context" is such a block that either has dimensional attributes (height,margin, etc.) defined in flex units or is contained in a block that has @flow attribute defined.

CSS doesn't have a notion of a property being 'undefined'. I thought that in your proposal, 'flow' had a default value of 'vertical' for blocks. So this won't work.

By the way, what happens when flex-units occur in contexts like tables and relative and absolute positioning?

HTML tables already have a concept of flex units. They are named there "relative length" units.

OK but what happens when you use flex-units in tables? This needs to be defined.

In this terms flex lengths and dimensions of position:absolute and position:fixed elements can be computed against their layout containers too.

Thus: div { position:absolute; width:25%; height:25%; left:1*; top:1*; right:1*; bottom:1*; }

will position such an element in the middle of abs. pos. container.

OK but how is this going to interact with the rules here, for example: http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width

position:relative elements do not have concept of layout container for computation of left,top,right and bottom so flex values for these attributes are treated as undefined.

What does 'undefined' mean? 'auto'?

Adding flex-units support seems to me to be a very invasive change that will affect large chunks of the CSS spec and many parts of existing layout engines. I think the flexbox spec, or something like it, will be much easier and lower risk, and therefore much more likely to be successful. I think we should continue working on it and not wait for flex-units to be worked out.

flexbox as a flexible entity will have exactly the same set of implications that needs to be resolved.

Flex element in David's proposal is exactly:

element { width:1*; } or element { height:1*; }

I cannot see of how it will be simpler to resolve.

Flexboxes are simpler because only width or height can flex --- no margins, no padding or anything else. That means, for example, no changes to margin collapsing are required. More importantly, since flexboxes are their own display model you don't have to worry about interactions with floats or clearance or positioning or modifying any existing layout specs or implementations. You can just say that 'float' and 'clear' on flexboxes is ignored. You could forbid positioning too, but allowing relative positioning is harmless and absolute positioning would be fairly easy to define.

You do have to account for how flexboxes behave in non-flexbox containers, and how non-flexboxes behave in flexbox containers, but this is considerably easier than reevaluating everything that already exists.