Re: [css3-flexbox] Argh, architectural problems

This sounds great to me. I agree that we only need the entire flexbox to be
baseline-aligned and having flexible lengths was so much more intuitive.

On Fri, Jan 21, 2011 at 11:05 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> 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
>
>