Re: Additive vs absolute flexes

My answers are in blue this time:


From: Robert O'Callahan 
Sent: Tuesday, May 18, 2010 10:29 PM
To: Andrew Fedoniouk 
Cc: www-style ; sylvain.spinelli@kelis.fr 
Subject: Re: Additive vs absolute flexes


  On Wed, May 19, 2010 at 3:27 PM, Andrew Fedoniouk <news@terrainformatica.com> wrote:

    1) To get "approximately 5 times" on this particular setup you should have height of the view equal to 6500px with (10% error). 
    And if that "approximately" means 5% error then 13000px. I don't think this "approximately" makes any sense - 
    it rather appears as a hack. If you would use absolute flex units then you will be able to make mental model of your 
    layout. With additive flexes it is very hard to predict what you will get and why.

    Practically it is enough to define: 
      content-slot { height:4*; }
      bottom-slot { height:2.5*; }
    and it will work with the same effect on practical view sizes.

  Sylvain didn't think so.


    If such nonlinear setup is really needed then you can combine plain old percents with flexes to get 
    nearly the same effect.

  Please describe how that would work.
Something like this:

content-slot { height:4*; } 
bottom-slot { height:2.5*; max-height:calc( 100px + 15% ); } 

there are many variations of such things. But that is for real jedi as you can imagine.

 
    Screenshots that you provided are more complex than what you have defined above.
    They contain non-flexible sections. If you will try to define that sections and left flexes only 
    for the editor widget and list view widget then it will be completely different picture.
    And again there is horizontal splitter there - I doubt it will always follow your additive flex model.

  The splitter and the left and right sections aren't relevant.

I mean splitter that separates top and bottom parts.

    Further comments:

      There is something I don't understand. In xul, if you don't set an explicit width, the intrinsic content width is used instead. Setting a width is only an override of the " intrinsic content width". In the W3C simplification idea "just size each child proportionally to its flex value", intrinsic content width will not be take in account at all ? In this case I think we can find many other problematic use cases : 

        a.. in classic dialog box, set flex=1 on 3 buttons in a hbox become unusable (long labels will be cut prematurely), 

        b.. in a tree or listbox columns width will not be auto-adapted correctly (If I remember well, it was one of the big limit I found in extJs ui...), 

        c.. etc.
    I followed up to clarify these comments, especially the first one. This use-case is a horizontal box containing three labeled buttons with different length labels. When the box is as wide as the sum of the lengths of the labels, he wants each button to be the width of its label. When it gets wider than the ideal width, I think he wants each button to get an equal share of the extra space. When it gets narrower than the ideal width, he wants each button to lose an equal amount of space. He does not want one or more buttons disappearing beyond the edge of the box.

    Ha! If you have no ability to define paddings in flexes then sure you will need workarounds with additive model. 

    With flex units you can write just this:

    button.greedy { padding-left:*; padding-right:*; margin:4px;  }

  Good point.

  There are other more complicated cases that it doesn't work with. For example, if the buttons contained an icon and text, you might want extra space to appear between the icon and the text. But I just made that up so maybe it's not realistic. We need more use cases.
Not a rocket science either:

button 
{
   padding: 4px 1*;
   width: calc( max-intrinsic + 10% );
}

button img 
{
   margin-right:1*;
}

-- 
Andrew Fedoniouk

http://terrainformatica.com