Re: Publishing the flexible box model

On Sun, Jun 8, 2008 at 9:46 AM, Andrew Fedoniouk <news@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.

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]