W3C home > Mailing lists > Public > www-style@w3.org > January 2011

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 12 Jan 2011 10:17:29 -0800
Message-ID: <AANLkTik=ZXEtLrz9WEGG6riFhanQmxzr+TdRL-0YPSZX@mail.gmail.com>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: www-style list <www-style@w3.org>
On Wed, Jan 12, 2011 at 2:37 AM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> I have played a bit with flexbox recently because I wanted
> to tweak a bit my editor BlueGriffon and base the current
> New Document wizard on CSS3 FlexBox rather than on YUI Grids.
> In just a few words: it's *impossible* at this time.
> The reason is that the "flexibility" computation, ie the distribution
> of remaining space, is done AFTER the computation of the widths of
> the flexing elements. If one of these elements increases its width -
> for instance a paragraph containing a long text - then the widths
> are counter-intuitive and absolutely useless to Web Designers.
> Here's a good example:
>  http://glazman.org/forCSSWG/flexbox-test.html
> (use Firefox4 beta or WebKit)
> Nobody - except the CSS WG itself and I'm not even sure - will ever
> understand why the paragraphs make the first flexing box of the second
> section grow...
> But more important, nobody will ever understand what needs to be done
> to work around this, i.e. go back to the behaviour all web designers
> expect: the first box of the first and second sections should have
> same width whatever the content.
> I think we have an architectural issue here. Flexbox cannot be
> used in the most general case on the Web because of that issue; I'm
> close to thinking this module is useless as is.

Oh, come now, that's quite an exaggeration.  The problem is very
localized and can be fixed (I've been giving it a little thought, as
it was brought up to me privately earlier).

The issue is just that the current draft resolves the preferred width
for elements with ''width: auto'' in horizontal flexboxes as
'max-content' (that is, the width of the element's contents if you
don't take any optional linebreaking opportunities).

I'm not certain what the correct solution is, nor am I certain that
there even *is* a correct solution.  Your concrete use-case would help
here, Daniel.  In the example you give, what do you imagine the
preferred width should be?  Would it be better to have 'auto' width
resolve as 'min-content' (take *all* optional linebreaks)?

If you want elements to absorb space based *purely* on their flex, the
solution is to set width:0.  The 'width' property sets the preferred
width, which is used as the base atop which free space is assigned.

I agree that this isn't obvious behavior, and that it should be called
out explicitly in the spec as a service to authors.  There's a reason
I felt that "absolute" flex was easier to grasp than "additive" flex,
back in my original drafts.

> We need to discuss that with implementors,
> and in particular Mozilla since it probably has deep impact
> on XUL.

Flexbox is based on XUL, not the other way around.  This should have
no affect on Firefox's UI.

Received on Wednesday, 12 January 2011 18:18:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:54 UTC