RE: Flexbox Draft, with pictures!

> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Wednesday, May 26, 2010 1:07 PM
> 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.  ^_^

I will eventually write a long reply to long reply. I am not sure it makes sense to drill into multiple use cases in one thread, we should have a systematic discussion on each.

Speaking of use cases - a one-sentence statement describing a use of a feature and starting with "I want" doesn’t count as a use case, sorry. Neither it is helpful to say "I provided examples there" - most people don't have the luxury of listening to every single word you say or write. To have a meaningful effect, use cases need to 
 -- clearly show a problem that need to be fixed or value to be added, 
 -- be associated with a real-life, end-user or author scenario (this is critical for understanding its importance)
 -- be tracked systematically

Here is a good example to systematic approach to use cases:
http://dev.w3.org/csswg/css3-gcpm/uc.html 

And here is a well written use case:
http://lists.w3.org/Archives/Public/www-style/2010May/0527.html


If you like I can go over each statement in yesterday's email, but I would much rather see us switch to a more organized process. The several ways we track CSS21 issues may give you a few ideas on how organize 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.

I am glad to see we agree here - there is no goal to integrate Flexbox. It is goodness if some associated behavior finds its way elsewhere, and it is worth considering before Flexbox design is finalized. 

There is a delicate balance (now this is my opinion, hope you agree with this too) between future-proofing and overengineering. We have to be careful to not make flex-box harder to use because we generalize it for interaction with hypothetical future modules.

--Alex

Received on Wednesday, 26 May 2010 22:56:24 UTC