Re: Publishing the flexible box model

Robert O'Callahan wrote:
> On Sat, Jun 7, 2008 at 10:49 AM, Andrew Fedoniouk 
> <news@terrainformatica.com <mailto:news@terrainformatica.com>> wrote:
> 
>     Robert O'Callahan wrote:
> 
>         There will also be interesting interactions between flex-units
>         and clearance.
>         <div style="overflow:auto;" class="block-formatting-context">
>          <div style="height:1*;">Hello</div>
>          <div style="float:left;">Kitty</div>
>          <div style="clear:left;">Kitty</div>
>         </div>
>         Since we don't know the vertical positions until the end, we
>         can't know whether to clear or not. If we treat 1* as auto while
>         we compute clearance, the results are going to be really bad
>         when we apply flex at the end.
> 
>     As I said floats are not the best friends of flexes. But if flexes
>     and the flow attribute will be implemented you will see a dramatic
>     reduction of floats uses.
>     All cases when floats are used currently for horizontal block layout
>     purposes can be implemented significantly better and more reliable
>     with flexes.
> 
> 
> Many of them can use inline-block as well actually.

I agree in general.
But, due to the nature of HTML, use cases for inline-block are 
significantly limited. <span> is practically the only element that keeps 
display:inline-block afloat. <span> is declared in[1] as
   <!ELEMENT SPAN - - (%inline;)* -- generic language/style container -->
that disables many potential use cases.

> 
> Unfortunately floats are a reality and you need to specify something 
> that makes sense for how floats and flex-units and clearance interact, 
> because even if authors shouldn't use them together, they definitely will.

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.

That simply makes floats and flexes independent.

> 
> 
> 
>         I'm not saying these difficulties are insurmountable. But I hope
>         it's clear that integrating flex-units into the existing CSS
>         layout specs would create many issues that have to be analyzed
>         and specified. It's not good enough just to wave our hands and
>         say it's all obvious; the issues raised already are not obvious
>         and we've only just scratched the surface.
> 
>     Opportunities that flexes provide outweigh possible issues
>     significantly. I wish flexes were in CSS from the very beginning.
>     That would simplify spec significantly (in particular all about
>     floats). And yet it will make obsolete that holy-wars about tables
>     used for layout purposes. Flexes give even more than you can do with
>     html tables.
> 
> 
> You may be right, but we have to deal with the way things are.
> 
> 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.

Please read:
http://www.w3.org/TR/html401/types.html#type-length

That, by the way, is one more thing that does not allow CSS
to reproduce table layouts in full.

Flex computation is defined for the cases when you have
container and one or more elements and attributes competing
for free space distribution inside that container.

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.

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.


> 
> 
>         So, we need a spec proposal that carefully considers all the
>         possible interactions between flex-units and CSS layout where
>         flex-units can be used, and describes how issues (such as the
>         ones already raised) are resolved.
> 
>     I agree. The problem is that I am personally is not that good in
>     writing specs. If someone will help me than we can come up with
>     something.
>     In principle it not going to be very complex definition.
> 
> 
> I am not as optimistic as you.
> 
> 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.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

[1] http://www.w3.org/TR/html401/struct/global.html#h-7.5.4

Received on Saturday, 7 June 2008 21:47:15 UTC