On Wed, Jun 11, 2008 at 7:59 AM, Andrew Fedoniouk <ne...@terrainformatica.com <mailto:ne...@terrainformatica.com>> wrote:

For position:absolute elements flex values are treated as having 'auto' value.

But as I said before it is a desire expressed by practical use to allow left/top/right/bottom flexes. So to have flexible absolute positioning: { position:absolute; left,top,right,bottom: 1*; }

These are mutually exclusive, so which are you proposing?

> > > Here is a screenshot if you wish: > http://terrainformatica.com/htmlayout/images/css-menus.png > > Nice example, but it doesn't illustrate my question since the abs-pos > element doesn't have flexunits on it. > > By the way, you probably should have a close look at your decision to > make block descendants of an element with 'flow' all block formatting > contexts. That means that margin collapsing never happens across the > boundaries of these blocks, so the discussion we had earlier about > margin-collapsing and flex-units is moot. That's probably a good step > but apparently that's not what you've implemented. You probably should > also work out more precisely what you mean by that restriction to make > it clear exactly which blocks are affected and how.

I did not say that "block descendants of an element with 'flow' *all* block formatting contexts."

Only if float appear somewhere inside block in flex context that block is said to be block formatting contexts for that float element.

That's not what you said. Here's what you said:

*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.

I guess it's unclear whether "contained" on the last line means transitive containment or direct containment. But this definition does not limit itself to affecting floats only.

Note that CSS does not currently define what it would mean for a a block to be a block formatting context for floats only but not for other purposes.

I do not say that changing spec will be trivial. Changes need to be done in any case. I am saying that magnitude of changes will be the same as for flexbox as for flex units.

I've given examples that require spec and implementation changes for flex-units but not for flexboxes, so this is not true.

But it is better to add such mechanism once and in the version that is known to be more flexible/universal upfront.

That could be true.

Concept of flexes is natural for human and is well known and obvious for people who make web design professionally.

That is true, but it's true for flexboxes too.

Tables are using flex concept already. Badly defined/specified but it is there. Flex units will help to formalize this too. At least for things like display:table-cell flexes will allow to get to HTML tables as close as possible in CSS.

See David Baron's message about that.