Re: [CSS3] Flexible Flow Module, proposal.

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.

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.

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.

>>
>>> 1) What you call flows are actually XUL flexes, and thus should be
>>> handled with the XUL box model.
>>
>> What exactly is "XUL box model" and how it is related to "CSS box  
>> model"?
>>
>>> Many of those properties are already implemented in Mozilla (with
>>> -moz- prefix). You can find them at
>>> <https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions>
>>> and you can find a proposal for the Flexible Box at
>>> <http://damowmow.com/temp/csswg/flexbox.html>.
>>
>> Seems like each of UAs have its own unique set of features for many
>> reasons. That does not imply that they should go to the common set.
>> If FF is using XUL based chrome then it is probably makes sense to
>> wrap XUL flex model into something CSS-ish.
>
> But David Hyatt noticed that those properties are also in WebKit. So,
> if we need a new feature, it probably makes sense to reuse what exists
> now (and maybe someone already uses)

I didn't just notice they were in WebKit.  I implemented them in  
WebKit. ;)

>
>
> The problem is...
> "Flow" is exactly equal to "display-model". The difference? Probably
> just the name.
> You wanted to introduce "flow: table". What is the difference with
> "display-model:table"?
> In addition, with "display-model", you don't need to define the
> interaction with "display", that is just a shorthand: that is, you
> don't need "flow:default".
>

Yeah, it seems like flow = display-model.  I don't much like either  
name.  They are basically the same though as far as I can tell.

dave
(hyatt@apple.com)

Received on Sunday, 12 April 2009 22:12:34 UTC