I personally don't know how hard this would be, but seeing as Neil, bz and I have all at some point expressed the idea that reusing new-style flexbox stuff to do old-style flexbox / XUL stuff "would make the world better", so I guess it was time I filed a bug. :-) dholbert, reliable sources tell me you might be one of the better-informed people regarding how difficult this would be. Can you give an estimate, and/or list some problems with this suggestion, and/or help figure out how to break this down if necessary? Some context: http://logs.glob.uno/?c=mozilla%23developers&s=6+Feb+2014&e=6+Feb+2014#c878951 and further discussion with bz/NeilAway, and today: http://logs.glob.uno/?c=mozilla%23developers&s=2+Jul+2014&e=2+Jul+2014#c1000577 and further.

I'd suggest holding off on any serious conversion effort until these bugs are addressed: bug 1015474 (changing the default minimum sizing behavior of flex items) bug 1032922 (renaming a keyword) bug 1018143 (perf issues w/ nested flexboxes)

I think we're probably good to proceed here -- all of the bugs in comment 1 have been addressed, and I don't know of any other big outstanding flexbox behavior-changes or perf issues. Unfortunately, I'm not very familiar with XUL (and I haven't done any experimenting with new-style-flexbox-inside-of-XUL), so I'm missing that part of the "how hard would this conversion be" equation. But basically, I'd expect we can try putting "display:flex" on things that were formerly "display: -moz-box", and renaming other properties as I described in this mozilla.compatibility post: https://groups.google.com/d/msg/mozilla.compatibility/yHLklHP-_5E/0ydYrKF_ehoJ ...and see how it works. :) This chunk of the spec may be handy, as well: http://dev.w3.org/csswg/css-flexbox/#flex-common In particular: - "flex: none" for inflexible things - "flex: <positive-number>" for items that should divide up all the space proportionally - "flex: <positive-number> 123px" for items that should *start* at a fixed size and then divide up *extra* space proportionally. (substitute "auto" for "123px" if you want to start at the auto-width/auto-height) ...and note that flex items will be clamped to their min-content size, by default (though it's a bit more complicated[1]); I believe this is different from XUL. Just add "min-width:0" if you really want the thing to be shrinkable down to nothing, despite having a larger-than-0 min-content size. [1] http://dev.w3.org/csswg/css-flexbox/#min-size-auto

(In reply to Daniel Holbert from comment #2) > In particular: > - "flex: none" for inflexible things > - "flex: <positive-number>" for items that should divide up all the space > proportionally > - "flex: <positive-number> 123px" for items that should *start* at a fixed > size and then divide up *extra* space proportionally. (substitute "auto" > for "123px" if you want to start at the auto-width/auto-height) Note that XUL has a bunch of mapped attributes. Unlike HTML, these sometimes override style (in particular they sometimes need to be able to override inline style, although I don't know whether they need to be able to override important style). The obvious ones are these: * { flex-direction: row; } *[orient="vertical"] { flex-direction: column; } *[dir="reverse"] { flex-direction: row-reverse; } *[orient="vertical"][dir="reverse"] { flex-direction: column-reverse; } *[ordinal] { order: attr(ordinal); } *[flex] { flex-grow: attr(flex); flex-shrink: attr(flex); } *[pack="start"] { justify-content: flex-start; } *[pack="end"] { justify-content: flex-end; } *[pack="center"] { justify-content: center; } *[align="stretch"] { align-items: stretch; } *[align="start"] { align-items: flex-start; } *[align="end"] { justify-content: flex-end; } *[align="center"] { justify-content: center; } > ...and note that flex items will be clamped to their min-content size, by > default (though it's a bit more complicated[1]); I believe this is different > from XUL. Just add "min-width:0" if you really want the thing to be > shrinkable down to nothing, despite having a larger-than-0 min-content size. Actually XUL clamps to min-content size even with min-width: 0 since that used to be the default. Instead XUL uses min-width: 0% to allow the flex to shrink down to nothing. As nobody uses min-width: 0 I don't think it makes any difference in practice.

(In reply to neil@parkwaycc.co.uk from comment #3) > * { flex-direction: row; } This ^ is unnecessary, since "row" is the initial value of this property anyway. The other style rules that you mentioned seem reasonable, if we want to keep those XUL attributes working in a new-flexbox world. (as opposed to just using style) > Actually XUL clamps to min-content size even with min-width: 0 since that > used to be the default. Instead XUL uses min-width: 0% to allow the flex to > shrink down to nothing. As nobody uses min-width: 0 I don't think it makes > any difference in practice. Ah, right. Given that XUL expects this clamping (and its way of opting out of it -- "min-width: 0%" -- should work for new-flexbox as well), this part should Just Work.

BTW, we've got a patch that prototypes this behavior over in bug 1398963. Not sure if it'll land -- but if it does, it'd be a big step towards fixing this bug here. --> Marking that bug as a dependency.

Here are links to compare flex and non-flex results on linux: tart - https://mzl.la/2Clo7R6 ts_paint - https://mzl.la/2o1NnaL