Re: [css3-flexbox] intuitivity and width computation rules

On Thursday 2011-01-13 05:44 +0000, Sylvain Galineau wrote:
> Well, like Daniel, I thought that specifying box-flex meant I
> didn't have to set width. In my case at least, what may have
> contributed to this were the many super-simple examples and
> testcases which mostly involve boxes with very little or no
> content - very commonly the "1", "2", "3" flex sample seen in
> almost every blog post on the topic [1] - where you don't run into
> this situation.
> 
> I wouldn't be surprised if others end up assuming the same i.e.
> setting box-flex 2, 1, 1 does not require setting widths to 50%,
> 25%, 25%. And their reaction to being told they have to will often
> be "well, what's the point then ?"  
> 
> [1] http://www.the-haystack.com/2010/01/23/css3-flexbox-part-1/

Having flex that's in addition to an intrinsic width is pretty
important for dealing with containers (e.g., for things that act
like widgets).  For example, if you consider something like the URL
bar in Firefox or IE9, you have something like this:

  <urlbar>
    <favicon />
    <span>URL (text)</span> <!-- has flex -->
    <icon />
    <dropdown />
    <reload-stop-button />
  </urlbar>

A widget like this can be constructed with a flexbox layout:  the
span would have flex, and the other things wouldn't.

If you then want to put this widget inside a larger toolbar in which
other items have flex, you might end up with something like this:
  <toolbar>
    <back-button />
    <forward-button />
    <urlbar>       <!-- flex: 3 -->
      ...
    </urlbar>
    <searchbar />  <!-- flex: 1 -->
  </toolbar>

If what you really want in this case is the flexible pieces inside
each of these widgets (urlbar, searchbar) to flex according to the
ratios of the flex on the widgets, such that the flexible pieces
inside the widgets hit 0 at the same time, then you need additive
flex; if you have a width that is *only* flex then the flexible part
inside the widget with more non-flexible things in it will be
cheated out of width, possibly significantly.

The lack of additive flex would force content authors to flatten the
content tree and make it harder to mantain pieces as independent
widgets.


Now I agree there's also substantial demand for flex that doesn't
add to an existing intrinsic width.

I think the key questions are really:

  * How do we enable authors to choose between these behaviors?

  * Which one should be easier (i.e., the default)?

Tab had one proposal with the opposite default, in which flex was
expressed using flex units instead of a flex property, and then
choosing additive flex required using calc().  This is a bigger
change to the existing flexbox model, and probably would lead to
higher implementation and specification complexity.  It's not clear
to me whether it would lead to better or worse results for authors.

Flexbox complements the existing layout models already in CSS, so we
should not only consider which layout scenarios are more important
for authors, but also which ones are more likely to be done using
flexbox because they're hard or impossible in the models that
already exist.

I strongly believe that flex as something that adds to the intrinsic
width should be possible.  I don't have strong opinions about what
the default should be, and I'd be interested in the experiences of
people who have done substantial authoring using existing flexbox
implementations.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Thursday, 13 January 2011 06:25:13 UTC