Re: Flexbox Draft, with pictures!

On Tue, May 25, 2010 at 2:59 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
>        1) The Flexbox spec is currently in fairly stable state. It had no changes for a year, there are two generally compatible partial implementations. It is well received, and there seemed to be no major issues (at least until recently). It would be reasonable to expect Flexbox draft to move to CR fairly quickly, but that is not what will happen if we switch to an entirely new draft.

Indeed, that's a concern.  That's why I originally limited myself to
fairly surface changes/reorganization.  But after putting
significantly more thought into it, I found some problems that I felt
were both significant and unable to be addressed by minor changes or
additions to the current flexbox spec.

I do think that the current spec is both elegant and relatively
simple.  But I think it draws itself into a corner with that solution,
for several reasons:

1. The current draft defines all the pack/align strategies in terms of
simple keywords that are analogous to vertical-align and text-align
values.  This makes it easy to understand, but it also limits what can
be done.  New alignment/packing strategies must be added as new
keywords; there is no ability for authors to innovate on their own.
This is sufficient for text, where this paradigm was borrowed from,
because text layout has been more-or-less solved due to literally
centuries of experience.  Application design, though, is a different
story.  I've already come up with a few cases where I'd prefer a
packing/alignment slightly different from what is currently specified.

2. We really want to reuse the concept of flexibility.  Template uses
a notion of flexibility, table uses it (de facto - * units aren't
defined in any CSS spec right now), abspos could really benefit from
it - flexibility is a powerful concept that I'd really like to reuse.
What I specifically want to avoid is three or four different
implementations of flexibility, one for each area in which it is used.
 That's precisely what we're looking at with the current state of
affairs, though.  Pursuing local maximums of simplicity in each area
will, I fear, lead to a significantly worse result in total.  I think
that flex units are only a *tiny* bit worse for local complexity (and
even that's arguable - authors already know how to use the
width/height/padding/margin model to size/position things) but are a
big win in global complexity when they can reuse all of their
knowledge between all the places where flexibility is used.

3. Keyword-based alignment, even if it had greater flexibility,
doesn't play as well with animation and such.  For example, take the
following markup:

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

This would give you a horizontal navbar, with the height of each
clickable region being the full height of the bar, but the actual link
text starting at the bottom of the box and transitioning up to the top
when you hover.  I've seen this precise effect done with javascript on
several sites; you can't currently do it in pure CSS unless you know
the precise height of the navbar and the link text (so you can do
explicit padding).

Even if we extend things to allow transitioning between keywords, we
still have difficulties doing explicit animations, unless we allow
more keyword-based calc() expressions.  We sorta want those in any
case for some things, but I don't think they're very easy to use.

4. It's seemingly impossible to do *actual* absolute flexes in the
current spec, though that may just be an implementation issue that can
be appropriately clarified in the spec and fixed in implementations.
Children of flexboxes seem to use the min-content width for their
preferred width even if you explicitly set width:0.


> It is perfectly fine for a working draft to change a lot before becoming a standard, it is fine to even be dropped and replaced by something else. It is somewhat surprising to see that potentially happening with this particular one though.
>
>        2) Although it is fine for a stable draft to change significantly, a major change needs a major reason. For example
>
>                - solving major problems
>                - addressing new important use cases
>                - consistency with other standards, existing or emerging
>
> We don't seem to have any of the above, at least so far. If we end up addressing approximately same use cases with different syntax and different algorithms, we should strongly consider iterating on existing spec.

Hopefully my above explanation addresses each of these.  I feel there
are substantial problems with the current draft (lack of individual
child alignment, global simplicity concerns), a substantial long-tail
of use-cases where finer control is useful/necessary that are shut out
by the current draft, and no clear way to share concepts from flexbox
with both existing and future modules that have near-identical
concepts.


>        3) On the merits of the proposed changes: I believe the original draft is very simple and elegant, and adds a lot of power with minimal new concepts. Proposed draft doesn't quite have leave that impression. This by itself is not an issue but as this is the list of my concerns I have to put it here.

It's fine to disagree about elegance.  ^_^


> With all this said, I would like to reiterate that what I would like to see the most is a stable, implementable flex-box specification, or something similar that achieves the same goal. I may disagree with a particular step along that way but my goals are the same and I am willing to work on getting there, even if it involves discussing (or even implementing) a spec which I generally don’t agree with.

I appreciate your forthrightness!

~TJ

Received on Tuesday, 25 May 2010 23:40:44 UTC