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

[css-flexbox] Summary of planned changes to Flexbox Module

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 19 Apr 2010 14:35:40 -0700
Message-ID: <v2udd0fbad1004191435ic9819e70z397273c27d806074@mail.gmail.com>
To: www-style list <www-style@w3.org>
In the course of digesting the Flexbox module, I ended up wanting to
make several relatively slight organizational/architectural changes to
make the module play a little better with existing CSS concepts and
make a little more sense to me.  Summary follows:

New display values (display-inside values)
==========================================

flex-up | flex-down | flex-right | flex-left | flex-inline | flex-block

Determines the direction of flow, and the mapping from
start/end/before/after to top/right/bottom/left

Flex-inline and flex-block are based on the block progression
direction and the writing-mode, and map to one of the first four
values.

Default is flex-right (equivalent to current draft's
box-orient:horizontal;box-direction:normal;).


Display Order
=============

box-direction is dropped for now.  It seems to be clearer to specify
the direction of flow directly in the display value.  I don't *think*
that we've lost anything by this.

box-ordinal-group is renamed to box-order.  Same effect.  I think it's
useful to be able to reorganize content from source order into a new
display order.  Template is one way to do this in two dimensions -
box-order offers a way to do it in a single dimension.


Alignment
=========

box-align and box-pack are unchanged in behavior (generally - I've put
some questions on the list about their precise behavior as specced).

box-align has its start/end values renamed to before/after.  It was
necessary to change one of these two properties; you can't have start
and end referring to perpendicular directions.  I chose box-align to
be changed so that the mapping makes the most sense for the default
values - before/after act like top/bottom by default, and start/end on
box-pack act like left/right by default, just like they would in a
page with normal english text.


Multiple Lines
==============

Changed box-lines to box-wrap, to more accurately describe the
mechanics behind it, and to map the values more closely to the
white-space property, which is its closest analog in static flow.
Values are `normal` and `nowrap`, default of `nowrap`.  (Not sure
about naming here.)

Added box-clear property, which takes `start` and `end` values.
box-clear forces a linebreak in a flexbox, regardless of the box-wrap
value.  `start` pushes the element onto a new line, `end` pushes the
*next* element onto a new line.  Ordinary line-wrapping takes place
after box-clearing happens (that is, first we do all the explicit
linebreaking caused by box-clear, then, if box-wrap is normal, we
check if any line is long enough to need wrapping).


Flexibility
===========

box-flex is unchanged.

box-flex-group is dropped.  Andrew claims that users of his layout
engine don't really use more than a single "group" of flex, as %s act
similarly enough to flexes to be a first layer.  If you do need a
second flex group, you can fake it by multiplying your second group's
flex value by 1000 or similar.

What's left
===========

There is a pending question concerning what the best directions for
start/end/before/after to map to is, depending on the display value.
Currently, here are my thoughts:

right: before is top, start is left
down: before is left, start is top
left: before is top, start is right
up: before is left, start is bottom
inline: before and start are equivalent to whatever the writing-mode
says they are
block: like inline, but before and start are swapped

Not sure how ideal all of these are.

~TJ
Received on Monday, 19 April 2010 21:36:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:26 GMT