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

> From: L. David Baron [mailto:dbaron@dbaron.org]
> Sent: Wednesday, January 12, 2011 10:25 PM
> To: Sylvain Galineau
> Cc: Boris Zbarsky; Daniel Glazman; www-style list
> Subject: Re: [css3-flexbox] intuitivity and width computation rules
> 

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

(Note to the editor: we need good examples like this in the spec imo 
i.e. simplified use-cases.)

This underlines how contrived and probably not that interesting the 1-2-3 
sample everyone uses actually is, or at least a poor representation of what
the feature is for. The real world is more likely to involve layouts like this 
one where 4 out of 5 elements in the container have a well-known width and the 
5th has a preferred width that can grow. 


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

That does makes sense; as the inflexible/flexible ratio in a widget goes up,
distributing the available width on top of intrinsic widths according to the 
flex ratio results in less 'starving'. 

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

Yes. We are talking about expectations of what the default behavior is.

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

And I don't disagree that it's useful; but it may not be understood that way 
(yet). 

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

Same here. Thank you !

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

Received on Thursday, 13 January 2011 17:59:50 UTC