[css3-flexbox] Argh, architectural problems

I have problems.  I keep trying to write my new ED of Flexbox, but
every time I get too far into it, it just starts feeling wrong.

As well, Daniel's recent confusion (echoed by several others in the
thread) about the role of 'width' and 'flex' and how it's unintuitive
to have 'width' not set the width but rather just set a parameter in
the flexible width computation, makes me pause.

So.  Let's talk.  This thread is for blue-sky theorizing (again) about
what the shape of Flexbox should be, in terms of what properties we
use to flex and align boxes.  (The other parts of flexbox, like
flex-index and flex-direction, feel uncontroversial, and so don't need
to be discussed further.)  I don't like to keep returning to base on
this subject, but I can't spec something that feels wrong.

Here's the issue.  We started with two fairly simple and consistent proposals:

The WD defined flexing and positioning mostly in terms of keywords,
with only one property ('box-flex') offering more fine-grained
control.  This had the benefit of being simple and easy.  The downside
was that it missed several use-cases; in particular, you couldn't put
flexbox children into groups with flexible space between them without
junk elements in the DOM (XUL solves this with the presentational
<spacer> element), and you couldn't align the contents of a
box-align:stretch flexbox child.

My original draft defined flexing and positioning entirely in terms of
flex units.  Widths, heights, paddings, and margins could all have
their lengths specified as flex units, and there was a relatively
simple algorithm for distributing free space between them (just a
generalization of the free-space algorithm in the WD for dealing with
flexible widths/heights).  This had the benefit of being simple and
uniform, but also missed an important use-case - you couldn't do
baseline alignment of the flexbox children using flex units.

I tried to reconcile these two things by taking the WD and expanding
what can create flexible lengths, so that auto margins were flexible,
and, depending on what day you asked me, padding could be made
flexible as well.  This approach plugs all the use-case holes, but it
ruins the common case, as the flex model is now complex and
non-uniform.  As well, there is still the criticism that having the
widths of boxes specified across two properties, with 'width' being
the subordinate one, is unintuitive.

I think I can recover this by instead starting from the other side, my
initial draft, and moving forward from there.

As far as I can tell, the use-cases for baseline alignment only
require the entire flexbox to be baseline-aligned; that is, there's no
need to have individual control over which are baseline aligned and
which are doing something else.  Given this constraint, I think I can
solve this easily by just having a separate alignment model (triggered
by a property) which treats flexible lengths differently to
intuitively baseline-align the flexbox children.  Otherwise, though,
flexing and positioning are done purely through flexible lengths
specified in the normal properties, like my initial draft.

I'm going to go ahead and start writing this to see if it still feels
right when I get into the details.  I'd appreciate feedback, or
suggestions on other ways to do this.

~TJ

Received on Friday, 21 January 2011 19:06:32 UTC