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

Re: [css3-flexbox] Argh, architectural problems

From: Ojan Vafai <ojan@chromium.org>
Date: Fri, 21 Jan 2011 12:11:23 -0800
Message-ID: <AANLkTin5AJg1P+LAHBZyUzq426ATc9=Pdu2sKfK4qHoH@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
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
Received on Friday, 21 January 2011 20:12:14 UTC

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