Re: [css3-flexbox] Trying out flex units again

On Wed, Feb 2, 2011 at 11:50 AM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> Reintroducing both kinds of flex for multiple properties is pretty powerful, but I am not sure I am all that excited about implementing that, as it is more work for not a lot of additional value IMO.
>
> It seemed that what we have previously discussed was in good shape... it needed prose and a resolution on baseline alignment. What has changed? Are there new important use cases that didn't work before?

I eventually had to disagree that it was in good shape.  I could hit
all the use-cases, but it was overly complex.

width/height was confusing to authors, because it depended on the
direct interaction of two properties (box-flex and width/height).
(I've had several unsolicited thanks from authors for returning to
flex units for width/height, since I asked for feedback.)

Alignment was turning out confusing as well.  There were a few
different directions for box-flex to go - it either controlled both
inside and outside alignemnt, or only controlled inside alignment
(auto margins controlled outside) or only activated baseline alignment
(auto margins and paddings controlled the rest).  None of these ended
up being particularly intuitive, especially when you combined them the
width/height/box-flex confusion.

Once I solved the width/height/box-flex confusion with flex units,
though, the third option above became the obvious simplest answer for
authors.  Now, everything is done with flex units, with two properties
on the parent that offer additional global control in each axis
(flex-align and flex-pack).  They both work identically, too - they
only work if there's space left over in their axis after normal flex
has finished, and they give options that are difficult/impossible to
achieve with the local control that flex units grant.  This is again
very simple to understand, and should work in a way that easily allows
future expansion if we desire it.

It is important to me that you're on board with these changes, though,
which is why I'm not doing any further work until we're on the same
page again.  Thanks for responding!


> The difference between the original spec and this draft is that instead of one flex value stored per element there is up to 70 (up to 5 values in flex() function, times margins, borders, padding, width and height). It is not all that difficult to implement but it is more storage, more testing and more complexity for the user... Is there a good reason?

Yes.  Without flex(), you can only specify preferred/minimum sizes for
width/height.  This means that in the minimum-space situation you're
*required* to either have inflexible margins/paddings, or let them
shrink to zero.  This can produce unattractive layouts - it's common
to depend on some minimal degree of margin or padding for legibility
and aesthetics.

(Not that it reduces your argument too much, but borders aren't
flexible.  Last time I tried to do that I got pushback but not any
support, so I'm just dropping it.  So that's only 50 values.  As well,
there's not just one value stored per element in the current model -
you still have to remember the values of margins, paddings, width,
height, and the min/max versions of the last two, plus we'd agreed to
do both positive and negative flex.  So it's more like 16 vs 54 (50 +
min/max-width/height), not 1 vs 70.)

This is theoretically more complex, in that there are more values, but
in practice it appears that authors find this simpler.  It seems to
map well to how people *want* to think about flexible boxes, so they
don't need to create new complexity in their mental models.

It's possible that flex() itself is too complex, though.  Widths and
heights already have min/max constraints, so they only need preferred
sizes and the two flexibilities.  I think my use-cases could get away
with just having margins/padding take a preferred size, a positive
flexibility (indicating it can grow, with no max), and optionally a
negative flexibility (indicating it can shrink, with no min).  Would
it make you happier to track only 3 values per property rather than 5?
 That would reduce the difference to 16 vs 34, and additionally
simplify the processing model somewhat.

~TJ

Received on Wednesday, 2 February 2011 21:11:42 UTC