W3C home > Mailing lists > Public > www-style@w3.org > January 2011

[css3-flexbox] Trying out flex units again

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 27 Jan 2011 17:44:50 -0800
Message-ID: <AANLkTi=PdhMUroZ1i-eDkHezmGP7VBc0-6cBkzmxw0A4@mail.gmail.com>
To: www-style list <www-style@w3.org>
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.


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.


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


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


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.

Received on Friday, 28 January 2011 01:45:43 UTC

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