1033225 - [meta] Ship XUL flexbox emulation (use CSS flexbox behind the scenes to implement XUL flexbox)

Status: NEW

(Core :: Layout, task)

Description

[:Gijs (he/him)]

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.

Comment 1

[Daniel Holbert [:dholbert]]

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)

Comment 2

[Daniel Holbert [:dholbert]]

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

Comment 3

[[e-mail]]

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

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to [e-mail] 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.

Comment 5

[Daniel Holbert [:dholbert]]

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.

Comment 6

[Brian Grinstead [:bgrins]]

Here are links to compare flex and non-flex results on linux:

  tart - https://mzl.la/2Clo7R6
  ts_paint - https://mzl.la/2o1NnaL