Re: Flexbox Draft, with pictures!

On Wed, May 26, 2010 at 1:33 AM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> 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.

I sent a longish email with several use-cases last night, so hopefully
that suffices for a start.  You did respond to that email, but your
reply was about direction/orientation, which I didn't mention at all
in the email, so hopefully you'll revisit it because I'm somewhat
confused.  ^_^


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

"baseline" is indeed a complex case and rarely or never makes design
sense to mix with other things.  But mixing top/bottom/center/other
alignment *can* make sense - I've given cases where that sort of thing
is used on the web right now, though in a fragile or js-using way that
can be fixed by flexbox.  Similarly, mixing packing strategies makes
sense - I've given an example of that.  Finally, more complex
alignment/packing than just adjusting margins/heights is useful, and I
provided examples there too.


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

I'm not trying to integrate Flexbox itself with the rest of CSS,
anymore than you need to in order to make it work on a page.  I
completely agree with the point you've made at a few FtFs that the
best course is to ensure that new layout modes interact as minimally
as possible with existing ones.  I'm talking about the base *concepts*
between them, though - I'd like to minimize the amount of relearning
that an author has to do to use a new layout mode, whenever possible.
This also means minimizing the number of almost-but-not-quite-the-same
concepts, because those are annoying and confusing.  Flexibility
happens to be a concept that we're now exploring in several
directions, and it would greatly benefit authors to not have to learn
4 subtly different definitions of how flexibility works.

So, I do *not* want Flexbox layout to mix with existing block layout
or table layout or whatever.  Within a flexbox, Flexbox rules apply
and that's it.  But when we actually spec * units in tables, flexible
rows/columns in Template Layout, simpler/advanced absolute
positioning, etc. I want to use the same concepts throughout if at all
possible.

~TJ

Received on Wednesday, 26 May 2010 20:14:03 UTC