W3C home > Mailing lists > Public > www-style@w3.org > June 2010

RE: Flexbox Draft, with pictures!

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Tue, 1 Jun 2010 16:20:40 +0000
To: David Hyatt <hyatt@apple.com>
CC: Tab Atkins Jr. <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-ID: <5258A1A783764C478A36E2BC4A9C497E0C1DA7@tk5ex14mbxc105.redmond.corp.microsoft.com>
I think a stronger argument for flex units would be making some future modules less hypothetical by at least having a sketch design for them. In particular, we know that every grid layout (e.g. XUL, XAML or tables) uses some sort of proportional units. Addition of a new kind of grid to CSS seems inevitable, it would be very interesting to see how the flex units as they are being defined would look there. I have some ideas here, will try to put something together soon.

Actually eliminating box-align or box-pack - I don't think that's necessary. These are intuitive and don't complicate implementation, even if the same can be done in a different way.

From: David Hyatt [mailto:hyatt@apple.com]
Sent: Wednesday, May 26, 2010 4:06 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.

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.

Received on Tuesday, 1 June 2010 16:21:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:47 UTC