Re: [CSS3] Flexible Flow Module, proposal.

On Apr 12, 2009, at 7:04 PM, Andrew Fedoniouk wrote:

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

Yes, it's that 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 )
>

Yeah, XUL boxes in Gecko do not implement flex groups, and this is the  
exact hack that authors used in the situations where flex groups would  
be needed.  I think this hack gets pretty gross though once you hit  
the need for three flex groups.   However I admit that we've never hit  
a use case in Gecko or WebKit where we needed more than two groups.

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

Yeah, I think I'm fine with leaving groups out for now.

dave
(hyatt@apple.com)

Received on Monday, 13 April 2009 00:11:36 UTC