Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Tuesday 11 May 2010

Standardizing XUL Flexible Boxes In CSS

Tab Atkins is working on a new draft spec for XUL-style "flexible boxes" in CSS. One issue that has come up is whether the XUL concept of "preferred widths" is essential or not. It would be really useful if XUL developers could contribute to the thread in www-style with feedback on that and other issues in related threads.

More detail: the children of a display:-moz-box element can have both width and -moz-box-flex CSS properties set on them. The width property sets a preferred width for each child. Any leftover space in the container is allocated to the children in proportion to their -moz-box-flex values. Likewise, if the preferred widths add up to more than the width of the container, the excess space is trimmed from the children in proportion to their -moz-box-flex values.

An alternative, simpler model would be to not have preferred widths: just size each child proportionally to its flex value. min-width and max-width could still be honoured. It's unclear whether this simpler model is too simple.

So if you have something to say about how you use flexboxes, now's the time to contribute and ensure your needs are addressed!



Comments

Neil Rashbrook
One obvious use case in Mozilla XUL comes to mind, and that is splitters; typically you have a flexible box on each side of the splitter, and the splitter sets their preferred widths as it is dragged.
jmdesp
I think the alternative model is the same as what the current model does when display:-moz-box is set to zero.
So it would be useful to see what people really using the current model would think about having display:-moz-box always set to zero, and in the xul of thunderbird/firefox how often such a value is used.
Mook
Yeah, setting width="0" on xul elements is a non-obvious trick needed to beat flexing things into shape in some cases. I'm assuming you don't mean that a row with a box with flex and a box without means the box without (regardless of content) will always be invisible, though? Sometimes the widths of things, especially those involving text, are impossible to know ahead of time.
Hopefully standardized flex will deal better with things like negative margins (display: -moz-box pretty much just ignores it). Songbird 0.6-ish had to do funny margin tricks in the player control area to properly center things. (That stood out in my memory as something we had to play with to get the flex to work right.)
sys
Our XUL application is an authoring tool. It looks like an Eclipse desk. Combining width and flex allow a really good automatic slots resizing for small and large screens.
Here is a very simple example with only 2 slots and 1 view in each slot (our tags are xul+xbl):
[matrix]
.[slot width="175" minwidth="100"]
..[wspNavView/]
.[/slot]
.[slot width="650" flex="5"]
..[contentsView/]
.[/slot]
[/matrix]
On a small screen : http://data.kelis.fr/files/sys/flexCssExample/smallScreen800x600.png
On a large screen : http://data.kelis.fr/files/sys/flexCssExample/largeScreen1400x1000.png
The left width evolve correctly. Only the flex concept with default width (and optionnaly minwidth / maxwidth) allow this behaviour.
With more slots (in our real application), this automatic sizing is really important for our users.