Re: Publishing the flexible box model

Robert O'Callahan wrote:
> On Wed, Jun 11, 2008 at 7:59 AM, Andrew Fedoniouk 
> <news@terrainformatica.com <mailto: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?
I am thinking aloud here.
There are two options that we may to consider:

1) For position:absolute elements flex values are treated as having 
'auto' value.
-or-
2) For position:absolute elements flex values are computed with respect 
of containing
block's box as if it has no other content except this one. Thus following:

div.center
{
    width:25%;
    margin:1*;
}
will position div.center in the middle of its containing block (if space 
allows).

Option #2 is clearly better as I've seen many times:
 "How to position absolute block that has height:auto in the middle?"
No way in modern CSS.

>
>
>         > > >     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.
Yes, that needs to be worked out.

David in his proposal uses following asumption:
"The 'float' and 'clear' properties do not apply to children of box 
elements".

That can be reformulated as:
"The 'float' and 'clear' properties do not apply to children of elements 
having not default value of flow."
I would add here also:  "except of children-containers that establish 
block formatting contexts by themselves".
This wording is not perfect - needs to have better version, but I think 
you understand what I mean.
>
>
>     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.
As I said:

box-flex: 1.0; is exactly
width:1*; or height:1*;

just exchange them and you will get pretty much the same wording.

Yes, in case of flex units there should be more words about margin 
collapsing and flexes in position:absolute/fixed but that is pretty much 
the only difference.
It is not like one approach is harder to define in order of magnitude 
than another.
>
>     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.
Beg my pardon but message about what?

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Tuesday, 10 June 2008 23:08:26 UTC