Re: Publishing the flexible box model

Robert O'Callahan wrote:
> On Tue, Jun 10, 2008 at 4:24 PM, Andrew Fedoniouk 
> <news@terrainformatica.com <mailto:news@terrainformatica.com>> wrote:
> 
>     Robert O'Callahan wrote:
> 
>         On Tue, Jun 10, 2008 at 2:23 PM, Andrew Fedoniouk
>         <news@terrainformatica.com <mailto:news@terrainformatica.com>
>         <mailto:news@terrainformatica.com
>         <mailto:news@terrainformatica.com>>> wrote:
> 
>            Robert O'Callahan wrote:
> 
>                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' :)
> 
> 
>         That doesn't answer my question. You need to extend the rules in
>         that section to describe what happens when flexunits (not just
>         "1*") appear for margins, padding or content.
> 
> 
>     For
>      flow:vertical;
>      box-sizing:content-box; ( default value )
> 
>     vertical margins, paddings, content and borders in flex units
>     share the same free space. So for style:
> 
>     div.inner { padding:1* 0; }
> 
>     This markup
>     <div style="height:YYpx; flow:vertical">
>      <div class=inner>First</div>
>      <div class=inner>Second</div>
>     </div>
> 
>     will be rendered as
> 
>     |------------
>     |
>     |First
>     |
>     |
>     |Second
>     |
>     |------------
> 
>     Rule is simple: free space is distributed among all lengths
>     in the direction in the block that establishes box with free space.
> 
> 
> What does that have to do with absolute positioning and
> http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width ?

There is nothing special with this in respect of flexes. Or I do not 
understand your question.

You calculate positions of elements including flexes.
After that you will have "would-be-position"s of absolute
elements and you replace them accordingly to their left...bottom
attributes.

Is this what you were asking?


> 
> 
>            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.
> 
> 
>         No. The flex on the <p> is ignored because the container is not
>         a flexbox. If the container was a flexbox, then the <img>
>         elements would not float.
> 
> 
>     Exactly the same thing as with flex units. Just replace 'flexbox' by
>     'flow'.
> 
> 
> OK. So 'flow' creates something like a flexbox. One difference is that 
> all features of CSS are available inside 'flow' except for features that 
> cause trouble, like floats, which you disable when you discover they 
> cause problems. But the only features available inside flexbox are ones 
> we explicitly allow. Another difference is that you have to specify how 
> 'flow' interacts with the various display types, whereas since flexboxes 
> are their own display type that isn't an issue.

'flow' defines how *children* of some container are layed out.
Such container shall establish container box. Otherwise
flex units have no sense inside such element.

So any element with display-model:block-inside and
display:block | inline-block | table-cell | list-item
can be used as a flex container.

> 
> A few more questions about flex-units:
> 
> Does 'flow' apply to inline elements? If so, what does 'flow:vertical' 
> do on an inline element?

As I said flow is applicable only to elements that establish boxes - so 
to create bounds for flex length distribution. Inlines are clearly not 
such blocks.

> 
> How do flexunits work on inline elements that break across multiple 
> lines? e.g
> <span style="font-size:50px;">Foo</span> <span 
> style="padding-top:1*">A<br>B<br>C</span> <span 
> style="font-size:80px;">qux</span>
> Which line box(es) are used to determine the padding? Does each line of 
> the <span> actually get a different padding?

Flex units are defined only for blocks and block-alike elements. 
display: block | inline-block | table | table-cell | etc.

inline elements have no concept of dimension. In the same way
as width:100px does not work for inline elements in the same
way flex length units do not work there either.

<button style="width:1*; height:1*; margin:0">Text</button> has a 
perfect sense though. As container for inline-block elements is the
line box they are in.


> 
> How do flexunits interact with absolute positioning and auto top/left? 
> Is the hypothetical position for the content computed taking flexunit 
> margins/padding on the content into account?

Yes.

Here is a screenshot if you wish:
http://terrainformatica.com/htmlayout/images/css-menus.png

And here its style system:

/* top level menu band */
     menu
     {
       flow:horizontal;  /* top level menu is a horizontal bar */
       width:max-intrinsic;
       padding-right:1*; /* spring on the right - all items sticked
                            to the left */
     }

     menu li
     {
       display: block;    /* menu items are blocks*/
       position:relative; /* to make our popup relative to this one */
       height:1*;         /* all items in the menu bar have the same
                             height */
       padding:2px 4px;
     }

     menu li:hover
     {
       background-color:navy;
       color:white;
     }

     menu menu
     {
       flow: vertical;     /* popup menus are vertically replaced */
       min-width:100%;     /* at least it is caption wide */
       position:absolute;  /* out of normal flow */
       display:none;       /* non-visible normally */
     }

     menu > li:hover > menu
     {
       display: block; /* now it is visible */
     }

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Tuesday, 10 June 2008 07:03:35 UTC