W3C home > Mailing lists > Public > www-style@w3.org > April 2009

Re: [CSS3] Flexible Flow Module, proposal.

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Sun, 12 Apr 2009 17:04:32 -0700
Message-ID: <49E28190.1080308@terrainformatica.com>
To: David Hyatt <hyatt@apple.com>
CC: Giovanni Campagna <scampa.giovanni@gmail.com>, www-style <www-style@w3.org>
David Hyatt wrote:
> On Apr 12, 2009, at 11:29 AM, Giovanni Campagna wrote:
> 
>>
>> It depends on its parent. If its parent has a display of anything but
>> "box" / "inline-box" (or "flow", or "display-model"), its height and
>> width are computed as always (box-flex doesn't apply), if its parent
>> has a display (-model) of "box", its dimensions are computed with the
>> XUL box model, considering the intrinsic 100px x 100px dimensions.
>> This means that if there are no siblings and the width / height of
>> parent is "auto", the <div> is not streched, else it is streched to
>> fit the whole box (because box-flex is different than "0").
>> Only one of "width" / "heigth" is changed (the Used Value, not the
>> Computed), which one depends on the orientation of the parent
>> ("box-orient"). If there are siblings, the box will be streched in a
>> way that
>> (new_width - intrinsic_width) : box-flex = (new_width_sibling -
>> intrinsic_width_sibling) : box-flex_sibling
>> (assuming that both box-flex are different than "0")
>>
>>> In any case the 'flow' and flex length units solve three
>>> problems:
>>> 1) block alignment, horizontal and vertical (e.g. margin:1*, 
>>> padding:1*);
>>> 2) introduces extensible list of various layout managers;
>>> 3) adds flexes.
>>>
>>> And XUL flex system you refer to seems like is aimed for latter two 
>>> only.
>>
>> Did you forget box-pack and box-align?
>>
> 
> One of the things that makes flex units attractive is that they would 
> cut down on the number of additional properties.  For example box-align 
> could be done with flexing margins (although it would be somewhat 
> inconvenient, since the former is a property applied to the parent and 
> the latter would have to be applied individually to all children).  
> box-pack is simple to model using flexible units on padding.  
> box-align:justify can also be modeled using flex units on margins 
> (again, having to apply to each child).
> 
> One concern I have with flex units (which I mentioned years ago the last 
> time this topic came up) is that you lose the ability to lay an object 
> out at "width" and only flex into the remaining space.  That may not be 
> a deal-breaker though.  I definitely think it's worth considering 
> whether a new flex unit type could get the results we want.

David, could you elaborate more on the problem? Seems like I did not get 
it. Is it that "#A and #B" case?

> 
> XUL boxes have a couple of other features, including the ability to 
> re-order content (probably not critical to the draft, and should 
> arguably apply everywhere and not just to flexible boxes), and flex 
> groups.  Flex groups allow you to give priority to a cluster of flexes, 
> making sure that earlier groups get to flex to their maximum (or minimum 
> dimensions) first before the next group starts to flex.  This feature is 
> pretty critical to achieving certain layouts, and it's not clear to me 
> how flex units would model it.
> 
> (One example of where flex groups are relevant is with the Windows Vista 
> scrollbar.  The scrollbar track is flexible, but once it can no longer 
> flex at very small sizes, the scrollbar buttons begin to flex to smaller 
> sizes).  Safari RSS also makes use of flex groups in its layout of RSS 
> feeds, so in order to transition the flexible boxes used in Safari RSS 
> to a new system, we would need this feature still.

Consider that vertical scrollbar consists from 5 parts (buttons for 
brevity):

button.prev - button with "up" arrow.
button.next - button with "down" arrow.
button.slider - a.k.a. scrollbar thumbnail.
button.prev-page - space between button.prev and button.slider.
button.next-page - space between button.slider and button.next.

Then if scroll bar value is at 25% and view-size/doc-size is 10% you 
will have this:

@set v-scrollbar
{
   .prev,.next
   {
     height:10000*;   /* some big enough value */
     max-height:12px; /* we use special 'system-scrollbar-height'
                         value that comes from system settings */
   }
   .prev-page
   {
     height: 0.25*    /* 25% */
   }
   .slider
   {
     height: 0.10*    /* 10% - view-size/doc-size */
     min-height:12px; /* we use special 'system-scrollbar-height'
                         value that comes from system settings */
   }
   .next-page
   {
     height: 0.65*    /* 100% - 25% - 10%*/
   }
  }

The key point here is that "some big enough value" in .prev/.next.
As it is big enough then it will be in effect only when
other components of the scrollbar will hit their minimum values.

Someone may think that this is a hack of course but it works. :)

(That "big enough value" just needs to be larger than pixel value of
  scrollbar height if someone would want to go such deep in the math )


> 
> Flex groups could probably be modeled by adding on to the number of *, 
> e.g., 1* could put something in flex group 1 and 1** could put something 
> in flex group 2.  In my practical experience I've never needed more than 
> 2 flex groups, so maybe that's as far as we need to go with the feature.

So far I did not see the need for groups. They probably are needed in 
some peculiar cases but for that cases designers will rather put 
additional container rather than trying to imagine how these groups 
would work. Adding DOM elements is not perfect of course but will make
job done. In any case nothing stops to add groups later if people will 
ask for them.

> 
> dave
> (hyatt@apple.com)
> 
> 


-- 
Andrew Fedoniouk.

http://terrainformatica.com
Received on Monday, 13 April 2009 00:05:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:46:58 GMT