Re: Flexbox Draft, with pictures!

>From: David Hyatt
>Sent: Wednesday, May 26, 2010 4:05 PM
>To: Alex Mogilevsky
>Cc: Tab Atkins Jr. ; www-style list
>Subject: Re: Flexbox Draft, with pictures!
>
>>  On May 26, 2010, at 5:55 PM, Alex Mogilevsky wrote:
>>
>>  There is a delicate balance (now this is my opinion, hope you agree with
>>  this too) between future-proofing and overengineering. We have to be
>>  careful to not make flex-box harder to use because we generalize it for
>>  interaction with hypothetical future modules.
>
>It all comes down to flex units.  As long as we use units for flex rather
>than flexbox-specific properties, I think we're in good shape for those
>hypothetical future modules.
>
>
>Now the question is, do flex units really simplify the flexbox module?
>I think they do.
>

Yep. And the very first candidate for flex units is W3C frontpage:
http://www.w3.org/ . On some view widths it looses information.
(E.g. "Standards", "Participate", etc. menu on top)

>
>We can eliminate box-align and the customized stretching it does (which
>was obviously kind of like flexing anyway), we can support the justify
>value of box-pack via inter-box spacing flex units (whether via
>border-spacing or flexbox-spacing properties), we can support other values
>of box-pack via flex units on the container box's padding, we can support
>additive flexes (that happen after intrinsic sizes) as well as non-additive
>flexes (no intrinsic size involved)... the list goes on.

Not quite so. To be precise - just opposite :)

Absolute flexes are computed *after* you have intrinsic
dimensions and other min/max constrains computed.
If sum of mins is greater or equal than space inside container
no flex computation is made as no free space at all.

If you have two elements:
  A { width:1*; }
  B { width:2*; }

then computed widths will be in proportion 1:2.
If A will reach its min then B will take rest of space.
If B will reach its min then A will take rest of space.
If A and B will reach their max-width values then
some free space will be left undistributed.

Additive flex model is significantly more complex and less
obvious than that.
Additive flexes are computed against so called
preferred width (whatever that 'preferred' means) and so
flexes can as increase as decrease that preferred width to
get final value. So if you have this:

  A { box-flex:1; width:100px; }
  B { box-flex:2; width:100px; }

you cannot say what will be wider as it depends on many
factors.

>The syntax is more compact in most cases and easier to understand.
>

Yes.

>
>Flex units really are a great simplification that not only allow us to cut
>out three properties but also enable a whole range of functionality that
>the existing properties can't describe.

As I have shown couple of times in the list already it is just enough
to have one property that defines method of children replacement
and the flex unit per se. And it will cover everything useful that
http://www.w3.org/TR/css3-flexbox/ has now at the moment.

>
>I really think our initial focus should be on integrating flex units
>rather than trying to rewrite everything else about the module.
>

It should be some property that will trigger flex units computations.
E.g. if you have floats in some container you cannot use
something like margin-top: 1*; inside. At best it will create
"holes". Blocks with flexible dimensions have to establish
block formatting contexts (so it will contain its floats inside).
And it should be some property on the container that
will trigger this. In my case it is 'flow : horizontal | vertical | ... '

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Thursday, 27 May 2010 02:24:17 UTC