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.

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.  The syntax is more compact in most cases and easier to understand.

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.

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

dave
(hyatt@apple.com)