RE: Flexbox Draft, with pictures!

I think we have an understanding of each other's position, that is a good start for productive discussion.

The most important ingredient to getting to a good solution is use cases. If we consider current model insufficient because it doesn’t solve specific problems we have to be really specific about these problems, and we have to get convinced that changing this particular spec is the right solution.

Current spec has a value of being implemented and extensively used (especially if you count XUL) so it shouldn't be discarded lightly. Its simplicity is most likely coming from implementation and use experience, not from laziness. As a random example - you claim that lack of individual item alignment is a drawback. Now, try implementing alignment where 'baseline' is mixed with top/bottom/middle... it is a pain to define or implement, and it rarely (or never) makes design sense.

Just one more point before I get back to shorter threads on specific issues. We apparently have different view of importance of Flexbox layout having separate model and not interacting much with the rest of CSS. You are trying to integrate it more, and I think it is important not to. It is good to be separate because
-- it is a building block for a UI platform, and every successful UI platform I've seen is built of very simple and independent building blocks.
-- by being separate it provides a simple solution for previously complex problems, yet it doesn’t add any additional complexity to the overall model. It is a great role model for further extensions (including some that we will come up with from looking at use cases).

--Alex

> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Tuesday, May 25, 2010 4:40 PM
> To: Alex Mogilevsky
> Cc: www-style list
> Subject: 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 Wednesday, 26 May 2010 08:34:05 UTC