RE: [css3-flexbox] Trying out flex units again

Reintroducing both kinds of flex for multiple properties is pretty powerful, but I am not sure I am all that excited about implementing that, as it is more work for not a lot of additional value IMO.

It seemed that what we have previously discussed was in good shape... it needed prose and a resolution on baseline alignment. What has changed? Are there new important use cases that didn't work before?

The difference between the original spec and this draft is that instead of one flex value stored per element there is up to 70 (up to 5 values in flex() function, times margins, borders, padding, width and height). It is not all that difficult to implement but it is more storage, more testing and more complexity for the user... Is there a good reason?

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Tab Atkins Jr.
Sent: Thursday, January 27, 2011 5:45 PM
To: www-style list
Subject: [css3-flexbox] Trying out flex units again

I've finished the first draft of my attempt to do flexbox with flex units, similar to my approach in my first drafts on my blog.

I've reverted the spec at <http://dev.w3.org/csswg/css3-flexbox/> to dbaron's last draft, as my changes are substantial and potentially controversial.  Plus, it's good to have the older draft to refer to for now.  You can find the new spec at <http://dev.w3.org/csswg/css3-flexbox/Overview.new.html>.  I'll swap this to the main Overview.html file when the WG gives me at least a token approval that I'm going in an acceptable direction.

I'm finally, actually, happy with this draft.  It feels right to me.
I'll give a quick rundown of the spec and what it involves:

New display value
-----------------

Just changed the names, to 'flexbox' and 'inline-flexbox'.  'box' was far too generic of a term, given CSS's usage of it to refer to the nodes of the box-tree.

flex-direction
--------------

A combined form of the current draft's 'box-orientation' and 'box-direction'.  I've gone over why I think this should be a single property before.

flex-order
----------

Rename of 'box-ordinal-group', to fit with the flex- prefix and have a shorter, easier name.

Flex units
----------

Flexbox children can use flex units in their margin, padding, width, and height to specify that they are flexible, and by how much.

Flex units can be specified in two ways.  The first, using the 'fl'
unit, produces "absolute" flex, which starts from a preferred size of 0.  This fits the mental model of many people, as exemplified by several comments in Daniel's thread a little while ago.

The second way is to use the flex() function, which produces "additive flex".  In its simplest form, it takes a preferred size and a flexibility, like "flex(auto, 1fl)", which creates a flexible length with a preferred size equal to what 'auto' would produce and a positive flexibility of 1 (no negative flexibility, so it won't shrink if the flexbox gets too small).  You can optionally provide a negative flexibility and min/max sizes for the length.  Additive flex is necessary for many useful cases, as dbaron illustrated in Daniel's thread.

flex-pack
---------

Rename to match the spec's convention.  It's otherwise identical to the current spec.

flex-align
----------

This property is vaguely similar to the box-align property in the current draft.  If it's 'auto', it does nothing special - free space is distributed to the flexible lengths in the standard way.  If it's 'baseline', the flexbox children are first baseline aligned, then use a slightly modified algorithm to distribute free space to the flexible lengths in such a way as to maintain the content's alignment.  This is intended to be a simple and sufficient solution to the use-cases that require baseline alignment.  I would really love a good description of several such use-cases, so I can ensure I design the free space distribution correctly.  Right now the only thing I've got is "tabs".


I would love review of this.  Like I said in a previous thread, and several times personally, I just don't think the keyword-based approach to flexbox is viable.  The current draft has a few use-case holes that, when you try to plug them, produce something overcomplicated; as well, it's apparently unintuitive to have 'width'
and 'height' change to merely be inputs into the flex algorithm, instead of either fully respected or fully ignored.  This new draft hits the same full set of use-cases, but I think is really simple and easy to use.

~TJ

Received on Wednesday, 2 February 2011 19:51:26 UTC