Just FYI, bug 1790616 and dependencies are on autoland (and hopefully
will stick).
That bug turns on flexbox emulation for browser.xhtml, which means that
(almost, see below) all the browser UI will be rendered using flexbox
rather than XUL layout, including the tab bar, toolbar, popups...
If you see any odd layout regression with the tab bar or toolbar
customization, etc, please file bugs and needinfo me, they're usually
trivial to fix and I'm happy to fix them of course :)
Things that are already using XUL emulation before this patch include
about:preferences, DevTools, the profile chooser dialog, and the tab
area of the browser. It's expected that browser.xhtml is the hardest, so
eventually we should flip the default, but step-by-step...
Btw, thanks to Gijs / Dao / Julian Descottes / Itiel / Shane (and
probably others, I always miss someone, sorry!) for all their help with
reviews, it's been invaluable!
# What does it mean?
What it means in practice is that these things should work now where
they didn't work consistently or at all before:
* Percentages on sizing properties ({min-,max-,}{width,height}).
* Absolute / fixed positioning.
* Negative margins.
* Should interact properly with other kinds of CSS layout.
* Probably a long list of etceteras, these are just off the top of my
head.
This also means that writing test-cases or porting browser UI to
actually use display: flex rather than display: -moz-box should be
trivial-ish. The property mapping works as follows:
* display: -moz-box -> display: flex
* -moz-box-flex: N -> flex-grow: N; flex-shrink: N
* -moz-box-align -> align-items:
* stretch -> stretch
* start -> flex-start
* center -> center
* baseline -> baseline
* end -> flex-end
* -moz-box-pack -> justify-content:
* start -> flex-start
* center -> center
* end -> flex-end
* justify -> space-between
* -moz-box-orient + -moz-box-direction -> flex-direction
* vertical + normal -> column
* vertical + reverse -> column-reverse
* horizontal + normal -> row
* horizontal + reverse -> row-reverse
* -moz-box-ordinal-group: N -> order: N
Porting to flexbox allows you to use all the goodies
(align/justify-self, flex-basis, ...).
# Behavior differences
While it's very close (that's why this is feasible to begin with), flex
emulation is not an exact replica of our old XUL layout.
Here are the things that are more likely to cause changes, and how to
(usually) fix them, along with examples.
These are the ones that come to mind, if they're useful I can put them
up in the in-tree docs or so.
## width/height are more frequently honored
With XUL, something like width: 100px wouldn't quite do what it says. If
it had content that was wider than that it'd expand over that size, if
the container was bigger it'd flex over it.
What it means in practice is that a bunch of explicit width/heights need
to become min-width/heights.
An example of this could be <
https://bugzil.la/1795339>.
## Scrollable elements contribute more to the flex min size
(This is a rather annoying behavior with modern flexbox, IMO)
If you have an element which is flexible, but has scrollable overflow
(overflow: auto/hidden/scroll), it might still grow the surrounding flex
container based on the scrolled contents, rather than scroll.
The right fix is to have min-{width,height}: 0 on the flex item(s), or
alternatively contain: {size,inline-size}. contain is a simpler fix (you
don't need to specify min-{width,height} on all flex items), but is a
bit more aggressive.
Examples of this could be <
https://bugzil.la/1794499> or
<
https://bugzil.la/1793505>. <
https://bugzil.la/1795286> is an example
of the contain vs. min-* behavior making a difference.
## Minimum sizes are slightly different
On XUL, automatic minimum sizes of flex items are roughly calculated by
recursively adding all margin/border/paddings and min-{width,height} of
descendants.
On flexbox, the automatic content sizes actually lay out the element
(ignoring percentages, etc).
In practice the new behavior should be more intuitive (except for
scrollers as mentioned above), but sometimes it may make stuff grow
where it didn't before.
# What's missing?
At the beginning of the email there's a tricky _almost_. While almost
every XUL element has been ported to respect `display` (and thus use
modern flexbox when enabled), there are a few that aren't still ported.
My priority with this work is first making the front-end team's life
easier, then (eventually) make the layout team's life easier by removing
a lot of poorly-maintained code.
Given that, I plan to prioritize fixing first the elements that will
save paint to front-end devs.
My current order of priorities is:
## Menus
That is, <menulist>/<menupopup>/<panel>/<menu>/<button type=menu>.
These have a bunch of event handling code in layout code, which is
non-trivial to port. I'm hoping to just switch them all to modern
flexbox in one sweep by changing the layout class inheritance in
<
https://bugzil.la/1551637>.
If that somehow doesn't work I'll do the actual work to move all of them
to the DOM like buttons (<
https://buzil.la/1790920>), ideally also
simplifying some of the layout code.
This is the biggest source of weirdness coming from XUL layout that I
expect, and the most complex chunk of work, so I hope to address it
ASAP.
## Some label / description elements
The ones with `value` attribute in particular. The only requirement that
I'm aware of that CSS layout doesn't have is middle-cropping (which is
used e.g., for filenames in the downloads panel).
I haven't figured out a great solution for that just yet. We do have
some middle-cropping support for the file input element, so maybe I just
reuse that.
These are not particularly problematic since they are just one line, so
weird sizing issues are not expected to happen.
## XUL image elements
These use list-style-image etc, and are not particularly hard to port to
regular HTML layout, or convert to HTML img elements (or use content:
url()).
Same as above, these aren't expected to be problematic because they're
leafs and they behave pretty much like any other HTML replaced element
already. Given that, not the highest priority to remove to achieve the
first, but if you want a fun layout project please let me know, should
be a good clean-up.
## Scrollbars
These have been using XUL since ~forever, and right now keep doing so.
These are definitely not expected to cause trouble because they are very
special already, and we use the XUL in HTML. Probably one of the last
few things to go away.
## XUL treebody
This still uses XUL layout. In practice it doesn't seem to interact
poorly with flex emulation, so I haven't dug into porting it just yet.
Thanks for reading till the end, if you made it. Let me know if you have
any questions or so, happy to help!
Cheers,
-- Emilio