Re: Publishing the flexible box model

On Wed, Jun 11, 2008 at 7:59 AM, Andrew Fedoniouk <news@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.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]