Re: Publishing the flexible box model

Robert O'Callahan wrote:
> On Sun, Jun 8, 2008 at 9:46 AM, Andrew Fedoniouk 
> <news@terrainformatica.com <mailto: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.

You're right. Default value of the flow is shall be 'default'
(or 'auto').

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

That is defined in HTML tables already:
http://www.w3.org/TR/html401/struct/tables.html#h-11.2.4.4
(See Proportional specifications there)

I do not think that we need to invent anything else there.

Speaking about tables. It is not possible in modern CSS
to define table width by using solely CSS.
With flex units table width in default style sheet for HTML can
be defined simply as:

table { width:1*; max-width:max-intrinsic; }


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

I see no problems there either.
In most cases 'shrink-to-fit' is 1* exactly.
Practically in all cases 'auto' value can be replaced
by 1* value.
1* is a mathematically correct way of saying 'auto' :)

So:

div
{
   position:absolute;
   width:1*;
   left:25%; right:25%;
}
is exactly
div
{
   position:absolute;
   width:auto;
   left:25%; right:25%;
}

the same is say for:
div
{
   position:absolute;
   width:30%;
   left:25%; right:1*;
}

> 
>     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'?

Here (for position:relative) it means 'auto' or just '0' (for 
left,top,right and bottom)

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

Consider this:

<div style="overflow:hidden; width:xx; height:yy">
   <img align=left id=first />
   <p flex=1>...</p>
   <img align=left id=second />
</div>

You will have *exactly* the same kind of problems.

About flex paddings, consider task of vertical alignment of content
of some div. With flex units that is simple and naturally as:

div
{
   box-sizing: border-box;
   height:1*;
   border:1px solid;
   padding:1* 10px;
}

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

I do not see any problems here too.

For containers in static flow that have height equal to 'auto' there is 
no free space by definition (height:auto == height:intrinsic) so no flex
computations are required.
Flex computation happens only when container is getting size larger than
intrinsic size of its content.
So if you have lengthly document in scrollable container then you do not
need to run computation of vertical flexes.

As I said flex units perfectly fit in CSS. Even more, they will allow to 
finally formalize those fuzzy 'auto' and 'shrink-to-fit' cases in the
spec.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Tuesday, 10 June 2008 02:23:43 UTC