This is the new CSS Flexbox model -- using "display: flex", as opposed to the older "display: -moz-box" model. Also, in the spirit of avoiding vendor prefixes for experimental features, we'll be shipping this new flexbox implementation without a vendor prefix in development builds -- hence, "flex" instead of "-moz-flex". It'll be guarded by a hidden preference ("layout.css.flexbox.enabled") which we can toggle to make it available in release builds, too, once it's been sufficiently tested and had its kinks worked out.
Today's patch simply toggled that hidden preference to "on" in Nightly builds, and that change will be merged to Aurora (Firefox alpha) builds around January 6th, the next merge day. With some luck, this may continue to "ride the release trains" and be released as part of Firefox 20, but we'll evaluate its readiness when Firefox 20 is merged to the Beta channel and may toggle it off at that point (though anyone wishing to test flexbox would still be able to toggle the pref on for themselves).
So: please go forth and test the new flexbox support in nightlies, and file bugs for any issues you encounter! Eiji Kitamura's "CSS Flexbox Please" demo page is a fun place to start.
A few known issues:
- When printed, flex containers currently get truncated at page-boundaries (though I'm actively working on fixing that).
- The "order" property doesn't yet affect paint-order/layering (though it does control positioning) -- I've got a patch in hand that fixes this -- it's just awaiting review, and it'll hopefully land soon.
- The line-wrapping "multi-line" version of flexbox is not yet implemented. (That's the "flex-wrap" property and the shorthand "flex-flow" properties.) I'll hopefully get to this in the near term, but it's somewhat separate from the core flexbox functionality, so we opted to implement it separately.
11 comments:
Nice work...congratulations!
Hmm . I see your prove I am not a robot , but if I am a robot, then there are no instructions.
Anyway Great work!
Cool!
Is it generally Mozilla's goal to replace the XUL box model with CSS3 flex and grid?
Will, at some point, "XUL" be "replaced" (more like re-implemented) by a web components / x-tags based implementation instead of the current XBL-based one?
Thanks for the answers
Also note that the MDN has a tutorial on this.
https://developer.mozilla.org/en-US/docs/CSS/Using_CSS_flexible_boxes
This may be a good start, and don't hesitate to edit the page if you find any mistakes or to communicate us things that are missing from it.
This is great work Daniel :)
@jet & wg9s & Ben: Thanks! :)
@Andre: I'm not sure if XUL will be fully "replaced", but it is my understanding that Firefox UI will be shifting away from XUL at least in part (and perhaps entirely at some point) towards HTML layout models like flexbox and grid.
@teoli: Thanks for that MDN link! Looks like a great introduction & resource.
Any idea when flex-wrap will be available.
I'm working on a small mobile site targeting android users (chrome & firefox) and was hoping to use flexbox.
But I'll need flex-wrap otherwise I'll have to back to floats :(
@Anonymous: I can't project an exact date right now. Flex-wrap support is near the top of my priority queue, but not quite at the top.
Right now, the earliest I think flex-wrap could be checked in would be the Firefox 22 timeframe -- that will be the version of our development trunk (Nightly) in just over a month, and that version will go to release in late June, per https://wiki.mozilla.org/RapidRelease/Calendar
Sorry that it's not sooner :-(
It seems highly irresponsible to ship unprefixed versions of the flexbox properties when wrapping is going to be missing. There's no way to differentiate between the non-prefixed browsers: Opera (which supports wrapping) and Mozilla (which won't support wrapping). If Mozilla isn't supporting wrapping when my layout expects it, it is going to appear very wrong and in some cases, virtually unusable.
> There's no way to differentiate
> between the non-prefixed browsers:
> Opera (which supports wrapping) and
> Mozilla (which won't support wrapping)
Sure there is -- you can use feature-detection in script -- see the "rolling your own chunk here:
http://www.sitepoint.com/detect-css3-property-browser-support/
(replacing textShadow with flexWrap)
The "@supports" feature would also make this easier, once it's implemented & turned on everywhere, FWIW.
http://www.sitepoint.com/supports-native-css-feature-detection/
"you can use feature-detection in script"
Thank you for not addressing the point of my comment. The FF team should NOT be shipping the flexbox properties unprefixed unless support is complete. That's reckless and irresponsible, and they should know better.
I should not have to resort to feature detection in JS to weed out StupidBrowserA (that's you, Firefox). I've never needed it before, and if the team had done the right thing by shipping with prefixes, all I would have to do is not use the -moz- prefix so it can gracefully fall back on the styles I've provided for non-flexbox browsers.
Post a Comment