Re: Flexbox Draft, with pictures!

On Tue, May 25, 2010 at 3:36 PM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
>> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
>> Behalf Of Alex Mogilevsky
>
> <snip>
>>               - addressing new important use cases
> <even more snipping>
>
> +1 on this. Even if not new or important, documenting the use-cases that support
> the proposed changes would be very helpful. To the extent there *are* implementations
> of the current draft, some of its shortcoming might even be demo-able with testcases ?
>
> The set of use-cases that informed standard features are often poorly documented,
> if at all. While I don't expect this draft to change this, it has been partially
> implemented so they would be even more relevant. And it ought to be a lot easier
> to achieve consensus on changing a spec if there already are patterns out there
> that clearly demonstrate the shortcomings of the current solution. Apologies if
> they've been covered at various points but even a summary of the relevant input
> that was considered would be great !

I'll assume that the most important change, and the one that needs the
most explanation, is the dropping of box-pack/box-align and the
introduction of flex units.

There are both global (language design) and local (use-case) reasons
for that.  I've explored both of these at least partially in my
previous emails, particularly the one to Alex.

The global reasons are:

1. A property and keyword driven flexibility model means that you
cannot apply knowledge learned from using this layout mode to any
other layout modes.  It is specialized to the precise needs of this
layout mode.  Template and table layout both use flexibility, and
abspos would benefit from it as well.  Right now we're on track to
having 3 or 4 different treatments of flexibility, all subtly
incompatible, which is a huge lose for language design and
ease-of-authoring.  Flex units can unite all of these layout modes,
while also drawing on authoring knowledge already built up by
authoring in normal flow (using width/height/padding/border/margin for
manipulating layout is already familiar).

2. A keyword-driven flexibility model means that innovation in layout
strategy has to happen through standardization, not author cleverness.
 If there are useful cases hidden here that we aren't addressing with
the pack/align strategies we currently specify, we have to wait for
authors to discover it and bring it to our attention, then for us to
decide it's important, update the spec, and finally get
implementations to update.  This is a massive delay for something that
I think *will* occur.  It's acceptable for entirely new abilities, but
not for relatively subtle new layout strategies.

3. A keyword-driven flexibility model is inherently limited in the
complexity that it can express.  For example, currently all the
alignment keywords concern themselves with sizing/positioning the
border box of the flexbox children.  But I commonly want to position
the content instead, or in addition to the border box.  Handling this
as well means more keywords which, because they're conceptually close,
are probably going to be difficult to name.  At the very least, we'll
lose the simple mapping between box-align and vertial-align.

Local reasons:

1. I *really* want to be able to position the content within the box,
in addition to just sizing/positioning the border box.  I want to be
able to stretch the border-box to the height of the flexbox
(box-align:stretch) but then push the content to the bottom, or
suspect it in the center.  This is really easy with flex units:  "hbox
> * { padding: 1fl 10px; }" will stretch the border-box and then
center the content.

2. I want fine control over how I flex things.  Frex, I think you can
get a mildly interesting effect by slightly modifying the last
example: "hbox > * { padding: 1fl 10px; margin: .25fl 0; }".  This
lets the border-box of the smaller children *be* somewhat smaller and
centered, without forcing me to shrink it completely down to
fit-content height, and then suspend the content in the center of it.
There is a tremendous long-tail of things like this, where an author
will want some effect that is subtly different from what we believe
were the "major" cases.  I'd prefer that author's existing knowledge
of and familiarity with exerting fine control over layout with
width/height/padding/border/margin properties continue to be usable
here as well.

3. I want to control flexing/alignment on a per-child basis.  I
provided an example of this in my email to Alex:

<ul id=nav>
 <li><a href=foo>Foo</a></li>
 <li><a href=bar>Bar</a></li>
 <li><a href=baz>Baz</a></li>
</ul>
<style>
#nav { display: flex; min-height: 3em; }
#nav > li { width: fit-content; height: 1fl; display: flex; }
#nav > li > a { padding-top: 1fl; transition: padding 1s; }
#nav > li > a:hover { padding-top: 0; padding-bottom: 1fl; }
</style>

I've seen this particular case done on several websites, though with
js animating an explicit padding or top/bottom.

4. I want to be able to transition/animate lengths that are flexed
(see previous example for a concrete use-case).  I don't think this is
possible at all in the current draft.

5. XUL has spacers/springs, which are empty elements that just flex
their siblings apart.  These seem useful!  In the current flexbox spec
you have to actually add a meaningless element to your HTML so you can
give it a high box-flex or box-flex-group.  I'd prefer to not have to
pollute my markup with useless elements, and just flex margins
directly - you can do this with flex units.

That's all that comes to mind immediately.  Sufficient?  ^_^

~TJ

Received on Wednesday, 26 May 2010 01:13:37 UTC