702508 - Support parsing/computing multi-line flexbox properties "flex-wrap", "align-content"

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Daniel Holbert [:dholbert]]

CSS3 Flexbox includes both a single-line and a multi-line mode.[1]

I'm intending to leave out the multi-line mode from our initial flexbox implementation, as noted in bug 696253 comment 11, and to add multi-line support in a followup bug.

This is that followup bug.

[1] http://dev.w3.org/csswg/css3-flexbox/#multiline

Comment 1

[Thomas Stache]

Please note that Modernizr.js uses the "flexWrap" style property to detect support for Flexible Box Layout, with the result that Firefox 19 with the flexbox pref enabled still is detected as not supporting the FlexBox spec.
Probably worth for the Evangelism team to reach out to the Modernizr team about that...

And there's bug 562073 that should be duped to this one (or vice versa).

Comment 3

[Daniel Holbert [:dholbert]]

Thanks for the heads-up, Thomas! I just contacted Paul Irish, lead developer of Modernizr, to ask about that.

In the meantime, maybe we can get this bug fixed soon enough that it won't matter too much.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: patch 1: support "flex-wrap" property in style system

This patch adds style-system support (but not layout support) for the "flex-wrap" property.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: patch 2: support "align-content" property in style system

...and here's the similar patch to support "align-content" in the style system. Spec for align-content: http://dev.w3.org/csswg/css3-flexbox/#align-content

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: patch 2 v2: support "align-content" property in style system

(fixed a few whitespace issues that I noticed after posting)

These patches pass our existing /layout/style mochitests, FWIW.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Thomas Stache from comment #1)
> Please note that Modernizr.js uses the "flexWrap" style property to detect
> support for Flexible Box Layout,
[...]
(In reply to Daniel Holbert [:dholbert] from comment #3)
> Thanks for the heads-up, Thomas! I just contacted Paul Irish, lead developer
> of Modernizr, to ask about that.

(and it looks like it's getting some traction in an issue that one of the Modernizr devs filed as a result: https://github.com/Modernizr/Modernizr/issues/744 . Thanks again to Thomas for the heads-up on that.)

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 680278 [details] [diff] [review]
patch 1: support "flex-wrap" property in style system

Should the pref controlling this be the normal flexbox pref, or should it be a separate multiline flexbox pref, so that you can enable flexbox without enabling multiline yet?

Or are you planning to wait to land this until you've got multiline implemented?

r=dbaron with that resolved in some reasonable way

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 680288 [details] [diff] [review]
patch 2 v2: support "align-content" property in style system

r=dbaron with the same comments as the previous patch

Comment 10

[Daniel Holbert [:dholbert]]

(Planning on waiting to land until multiline is implemented, which will likely happen as other patches in this bug.)

Comment 11

[henryfhchan]

shouldn't this block the preffing on of unprefixed flexbox?

Comment 12

[Daniel Holbert [:dholbert]]

Probably not. We don't always implement 100% of the features in a spec before making it available, especially when the ready-to-ship code represents a useful and cohesive subset on its own & accomplishes the main goal of the spec.

Comment 14

[u465675]

How is the progress of this feature?
I think it's very important to the whole Web to have FlexBox fully functional since it's kind of a revolution to the way we layout our applications and websites.

It looks like Chrome and Opera already have it 100% or almost there.

How could I help with this feature?

Comment 15

[Daniel Holbert [:dholbert]]

diego: Thanks for your interest and for your offer of help!

I'm tentatively planning on working on this in the near-ish term, and it probably makes the most sense for me to work on it since I'm already familiar with the rest of the flexbox code that this would be refactoring / editing.  But if you're proficient in C++, you might be able to jump in and tackle this. (This would be a pretty tricky first Mozilla bug, though.)

If you're more of a HTML/CSS/JS coder, you could help out here by writing some good automated tests for this bug. (Probably using the "reftest" framework.)

Ping me on IRC if you're interested in either of those. (irc.mozilla.org, channnel #developers, and I'm dholbert)

Comment 16

[djn]

I have a CSS layout that uses multiline flexbox to achieve equal height columns in a multi-column layout, so that the column divider border line can be drawn all the way from the top-to-bottom of the column when flex is supported by the browser. This degrades nicely (by using conventional float techniques) on browsers that don’t support unprefixed flex at all (though without a full-height dividing border being drawn) and also on the released Firefox 20.0. Thus, all major browsers are catered for, and I get the column divider being drawn full height on Chrome, where flex is fully implemented.

Which is great. Except, of course, that this is now breaking horribly on the Firefox nightly (23a.01), as the flex item divs are all horizontally stacked next to one another, rather than wrapping within the intended page width (whether by multiline flex support, or the fallback floating divs). The problem here is that the Firefox nightly understands ‘display: flex’, and so tries to arrange the contained items (rather than letting them be handled with normal float techniques), but does so incorrectly because it does not understand ‘flex-flow: nowrap’. It looks like I’m going to have to significantly re-work a perfectly reasonable (backwards compatible) multiline flex layout to avoid the problems caused by Firefox’s half-complete implementation.

Is it too late to stop rolling out a half-implemented unprefixed flexbox implementation in the release version of Firefox? If not, may I ask that serious consideration be given to doing so? If a half-implemented version of flex goes ahead unprefixed, I believe that it is likely to set back the adoption of flex, as Firefox will be the sole browser to break otherwise reasonable (and nicely degrading for non-flex-supporting browsers) CSS layouts that use multiline.

Thank you for the consideration.

Comment 17

[Daniel Holbert [:dholbert]]

Not that it's an optimal solution, but can you stick your new-flexbox CSS in an "@supports" block for flex-wrap?

e.g.:
  /* fallback CSS goes here */
  @supports (flex-wrap: wrap) {
   /* new-flexbox CSS goes here (or, just the parts that depend on flex-wrap) */
  }

Comment 18

[djn]

That’s an interesting idea, thank you for the suggestion (and also for working on the flex implementation – it will be great when this is widely supported).

I tried the @supports rule, but unfortunately it isn’t working on Chrome (either the current 26.0.1410.65 release or the 28.0.1490.0 canary), so using CSS feature detection has the effect of disabling the flex on the one major browser that currently supports it. (The @supports rule is behaving as desired with the current Opera release, however.)

I see that caniuse.com is indicating that @supports will be available in the release version of Chrome 28, so perhaps that will become a viable option then. In the meantime, however, it doesn’t look like it is presently a solution.

Thank you again for the suggestion. I’m open to any other ideas!

Comment 19

[Daniel Holbert [:dholbert]]

Ah, I'm sorry to hear that - that does make things a bit trickier.

I believe you can still get the same effect with "@supports not" (which Firefox should honor), to do something like:

  /* fallback CSS goes here */

  /* new-flexbox CSS goes here (or, just the parts that depend on flex-wrap) */

  /* chunk to turn off new-flexbox code if 'supports' works and
     tells us that flex-wrap isn't supported */
  @supports not (flex-wrap: wrap) {
    .flexContainer { display: block }
  }

...and if you want to be more future-proof and you're worried that chrome might add @supports before they unprefix, then you'd probably want to tweak that @supports line to something like:
   @supports not (flex-wrap: wrap) and not (-webkit-flex-wrap: wrap)

> Is it too late to stop rolling out a half-implemented unprefixed flexbox implementation

I'd say it's mostly-implemented, not half-implemented. :) And expanding on comment 12:
 a) the subset we've implemented is self-contained & coherent, which is why we think it's worth shipping it at this point.
 b) multi-line support should hopefully be coming soon, but we don't want to prevent developers from taking advantage of the (more fundamental and more commonly desired) single-line flexbox support by gating it on multi-line support.
 c) Developers can use feature-detection techniques (like "@supports" or at least "@supports not", or using element.style.someCssPropertyName in JS) to tell whether the specific multi-line subfeature is present.

Comment 20

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #19)
>   /* fallback CSS goes here */
> 
>   /* new-flexbox CSS goes here (or, just the parts that depend on flex-wrap) */

(sorry, copypaste fail; ignore the "just the parts..." parenthetical there)

Comment 21

[djn]

(In reply to Daniel Holbert [:dholbert] from comment #19)
> Ah, I'm sorry to hear that - that does make things a bit trickier.
> 
> I believe you can still get the same effect with "@supports not" (which
> Firefox should honor), to do something like:

Yes that does seem to solve the problem – thank you for the pointer! (I confess to not having been up to speed on @supports as it is so new, and I hadn’t twigged you could negate the test. That’s very handy.)

> ...and if you want to be more future-proof and you're worried that chrome
> might add @supports before they unprefix, then you'd probably want to tweak
> that @supports line to something like:
>    @supports not (flex-wrap: wrap) and not (-webkit-flex-wrap: wrap)

Good idea, thank you. To get this to compile with Compass/Sass, I needed to write the rule with additional parens, like this:

   @supports (not (flex-wrap: wrap)) and (not (-webkit-flex-wrap: wrap)) { ... }


> > Is it too late to stop rolling out a half-implemented unprefixed flexbox implementation
> 
> I'd say it's mostly-implemented, not half-implemented. :)

That’s good news!

> And expanding on
> comment 12:
>  a) the subset we've implemented is self-contained & coherent, which is why
> we think it's worth shipping it at this point.

This is true. But surely it is highly desirable not to ship a partial implementation of a Candidate Recommendation that actively breaks conformant CSS using that CR? (A rhetorical question – no need for you to answer! Ditto those similar below.)

In general, I’d be in favour of shipping partial implementations of a Recommendation, but only when doing so isn’t going to break designs employing valid CSS. Shouldn’t it be a pretty high priority *not* to break the web?

I wonder whether other people experimenting with flex might not be put off when their layouts break on new Firefox versions. At the very least, a bunch of people over the next month or two are going to end up spending time trying to figure out what’s going with their designs breaking on Firefox, and then trying to find a solution...

Still, I (greatly) appreciate that you’ve given me a workaround, and I hope your helpful responses here might point a few other people in the right direction when/if they encounter similar problems.

>  b) multi-line support should hopefully be coming soon, but we don't want to
> prevent developers from taking advantage of the (more fundamental and more
> commonly desired) single-line flexbox support by gating it on multi-line
> support.

If multiline support is mostly implemented, wouldn’t this fact tilt the balance towards waiting just that little bit longer to ship a full implementation unprefixed? Couldn’t the current work be shipped prefixed in the meantime – the best of both worlds?

>  c) Developers can use feature-detection techniques (like "@supports" or at
> least "@supports not", or using element.style.someCssPropertyName in JS) to
> tell whether the specific multi-line subfeature is present.

Yes, this does salvage the situation. Until, at least, a browser vendor decides to have their browser respond positively to a feature query for a feature that’s only been partially (or non-compliantly) implemented... :-)

Anyway, thank you very much again for your help – I’m sorted now, and I’ve learned a couple of useful things from you today!

Comment 22

[Daniel Holbert [:dholbert]]

(In reply to djn from comment #21)
> Yes that does seem to solve the problem – thank you for the pointer! 

That's great to hear! Thanks for reporting back on that.

> If multiline support is mostly implemented, wouldn’t this fact tilt the
> balance towards waiting just that little bit longer to ship a full
> implementation unprefixed?

(I wouldn't say multi-line support is "mostly" implemented at this point, though it is partly-implemented (see attached patches), and it's nearing the top of my queue of things-to-finish. And it'd be several firefox-versions' delay, not a trivial amount of time.)

> Couldn’t the current work be shipped prefixed in
> the meantime – the best of both worlds?

If this were two years ago, then that's probably what we'd be doing, yes. However, Mozilla's current position is that vendor-prefixed CSS hurts the web. It seems like it'd work in theory, but in practice, there's a good amount of content that's been coded up to *only* use vendor-prefixed CSS (often with just -webkit) and has no unprefixed version -- and this ends up meaning that WebKit (or whoever the vendor is) has to continue supporting their prefixed property forever in order to avoid breaking such sites, and other vendors can never get a "correct" rendering unless they fake support for that vendor's prefixing.

So our current strategy is discourage the use of vendor prefixes, and instead to ship with new features unprefixed but disabled, behind an about:config preference, so that developers can test it, and then enable it (unprefixed) when it's sufficiently complete.  (I believe Blink has committed to doing something along those lines, too.)

Comment 23

[djn]

Thank you for the further comments :-)

Comment 24

[u465675]

Well, It has been sometime (1 year) I've worked with C++.
But I have no problems with the language.

I will be pleased to help with automated tests.
I just have to set my dev machine to build Firefox.
I'll do it this weekend and ping you at IRC as soon as I finish it.

Thanks for replying.

Comment 25

[Daniel Holbert [:dholbert]]

Attachment: patch 1 v1a: support "flex-wrap" property in style system [r=dbaron]

(The patches here have bitrotted a bit. Posting un-bitrotted versions of them.)

Comment 26

[Daniel Holbert [:dholbert]]

Attachment: patch 2 v2a: support "align-content" property in style system [r=dbaron]

Comment 27

[diegobfernandez]

What is missing to finish this?
I'm excited about this to be released!

Comment 29

[Daniel Holbert [:dholbert]]

(In reply to diegobfernandez from comment #27)
> What is missing to finish this?

Someone (probably me) needs to write the actual layout code to implement it. It's on my to-do list; I'm working on patches for bug 811024 at the moment, and this is likely what I'll be working on next.

The patches that I've attached here so far are just for adding parser support (so that we'll recognize the CSS property & its values), but they don't add the actual layout functionality yet.

Comment 30

[Irae]

I know Mozilla have it's own pace for things and that Firefox is evolving very fast. But I wanted to note that flex-wrap support is a major improvement for CSS and how we design content. Firefox is the only one lacking behind. More on this here: http://caniuse.com/flexbox

Only IE10 and Firefox are missing flex-wrap in its current versions. Even IE11 has it on it's beta and Firefox don't have it on Aurora yet. I don't intend to press anything, just to make clear how wanted this feature is and how important to designers this is.

Comment 31

[diegobfernandez]

As Irae stated firefo is the one lacking full support.
I think this bug needs the highest priority.
The Open Web need this to advance in layout evolution.
Hope every browser have full support to flexbox this year.

Comment 32

[adam.taylor]

Absolutely. Surely flexbox is one of the most important CSS3 properties; with it we can *finally* create proper layouts. 

Surely this must take priority.

Comment 33

[Daniel Holbert [:dholbert]]

This is next on my queue of medium-to-large projects to working on it, and I intend to be actively working on it within the next few weeks.

Comment 34

[Daniel Holbert [:dholbert]]

Gah, sorry for the mangled English there. (meant to say "projects to work on")

Comment 35

[Jordan Austin]

@dholbert Thanks for commenting on this. We're all hoping to see this in the very near future.

Comment 37

[ct5845]

Any update on this? Incredibly important property and a real shame to start including firefox "fixes" on top of the IE<10 stuff!

Comment 39

[Niloy Mondal]

I dont care for any of the fancy properties(as of yet), I just wanted to do simple vertical centering, firefox has completely broken flexbox as of now.

Comment 40

[Kevin Bennett]

Would love to see a fix for this one... flexbox is making my life ALOT easier on other browsers, but the current functionality of firefox is causing me serious headaches and workarounds.

Comment 41

[Alfonso Martinez]

Glad there's already a ticket for this, but would need to see some action on it. The current Flexbox limitations on Firefox make it nearly impossible to use - single line elements only, as nothing wraps properly. Do the world a favor and prioritize this one, guys.

Comment 42

[diegobfernandez]

dholbert will this land this year?
I really think it's one of the most important features to be implemented this year.
Even IE 11 is full compliant with the specs.

Comment 43

[Daniel Holbert [:dholbert]]

(In reply to diegobfernandez from comment #42)
> dholbert will this land this year?

That's the plan, yes.

Comment 44

[David]

Flex is going to be pushing the web and its layout forward. Firefox not including multi-line support is holding me back from using it in projects. I'm looking forward to this being corrected soon (hopefully by the end of the year).

Comment 45

[Kyli]

+1 this should be done soon to help progress web design paradigms. Glad so much more of flexbox is done, though!

Comment 46

[sjw]

It's already to late to implement the patch this year, isn't it? The current Nightly Build will be the last one that will be released this year.

Comment 47

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #43)
> (In reply to diegobfernandez from comment #42)
> > dholbert will this land this year?
> 
> That's the plan, yes.
(In reply to sjw from comment #46)
> It's already to late to implement the patch this year, isn't it? The current
> Nightly Build will be the last one that will be released this year.

"land" = "get checked into mozilla-central"

You're correct that it does take some time between that & when the patch makes it to a Firefox release.

Comment 48

[Kyli]

Can RetroInferno be blocked? Is that a thing you can do on Bugzilla?

Comment 49

[Vincze Márton]

Firefox is the only one not supporting flex-wrap among the top 5 browsers.

I need this to my all-purpose-responsive-super-mega menu implementation.

Comment 50

[Irae]

I world trade 20 engineers working on WebRTC or ecmascript 6, 7 or asm or even generators for 1 guy seriously working on flex-wrap. Not only for Firefox but for Firefox mobile.

Or maybe a better idea to migrate my "this won't work in internet explorer" banner to "this won't work in Firefox. I switched to Safari and one of the reasons is this particular bug.

Comment 51

[sjw]

What about setting a priority?

Comment 52

[Daniel Holbert [:dholbert]]

Priority is mostly just for bookkeeping / triage -- doesn't matter a huge amount -- but I'll go ahead and set it. This falls into the "P3" bucket (which basically means "we'd like to have this soon, but it's not a zero-day / firedrill type issue"). I've now set that field.

I'm currently working on implementing this, BTW.

Comment 53

[Daniel Holbert [:dholbert]]

Also: I'll likely convert this bug to be just about the style-system parts (the patches already attached), and I'll spin off a second bug for the layout parts (reacting to the CSS properties) -- that's the part I'm working on now. More to follow as the patches develop. The bugs' patches will still all want to land together; it'll just be a logical separation to make patch-review easier.

(If I do that, I'll use "clone this bug" so that the folks CC'd here will be CC'd on the second bug as well, so that you can stay in the loop.)

Comment 54

[Daniel Holbert [:dholbert]]

I'll be posting updated (unbitrotted) patches here shortly.

The unbitrotting addresses these changes that have happened on trunk, which affect the patches here:
- nsStyleConsts.h moved to a different directory
- flexbox pref removed
- COMPUTED_STYLE_* macros moved to a new file
- SETDSC_UNSET_INITIAL flag added to nsRuleNode

I also spun off bug 939901 for the layout changes that are required here (per comment 53).

Comment 55

[Daniel Holbert [:dholbert]]

Attachment: patch 1 v2: support "flex-wrap" property in style system [r=dbaron]

(unbitrotted, per Comment 54)

Comment 56

[Daniel Holbert [:dholbert]]

Attachment: patch 2 v3: support "align-content" property in style system [r=dbaron]

(unbitrotted, per Comment 54)

Comment 57

[Jen Simmons [:jensimmons]]

I'm very glad to see some movement on this. It's weird to live in a world now where Internet Explorer and all browsers support something that's been talked about for a while, and feels past time to be ready to use... and then the blocker is *Firefox*. 

What?
Everybody supports this except Firefox? 
What wormhole did I fall into?
Why am I not cursing that other browser instead?

I hope things are progressing well and, Daniel, you have space in your schedule to get this done in the next few weeks. Thank you for all your recent work to restore the universe where we Firefox is not the browser we are cursing for being behind. I await that day with much impatience, hoping this makes it into Firefox 29 (which, for reference, everyone else, will be released April 29, 2014: https://wiki.mozilla.org/RapidRelease/Calendar).

Comment 58

[Luis Martins]

Glad to hear Firefox is moving forward with this issue. As Jen Simmons said, this is a strange situation where Firefox is holding us back, when everybody else already implemented this.

Comment 59

[David]

That's great to hear, Daniel. Thanks for your hard work. Do you know whether this will be included within Firefox 29?

Comment 60

[Daniel Holbert [:dholbert]]

Thanks - yes, this is very likely to land well in time for Firefox 29.

(Note also that the remaining work needed for this is tracked in bug 939901, per comment 53 / comment 54).

Comment 61

[Daniel Holbert [:dholbert]]

Landed this (and the other helper-bugs for multi-line flexbox) on inbound:
 https://hg.mozilla.org/integration/mozilla-inbound/rev/8f49fff73d6e
 https://hg.mozilla.org/integration/mozilla-inbound/rev/2539dbed0ca8

(It should be merged from there to mozilla-central in the next day or so, and after that, it'll appear in the subsequent Nightly build.)

Looks like this is making it for Firefox 28, barring unforseen issues.

Comment 62

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/8f49fff73d6e
https://hg.mozilla.org/mozilla-central/rev/2539dbed0ca8

Comment 63

[Doug]

you guys have a good work-around for this?. it does not work in 26 and it has forced us to drop support for FF in our software, and use Chrome/Safari/IE instead . kind of sad considering you guys were my favorite browser 5 years ago

Comment 64

[Doug]

totally agree. i cant believe i'm endorsing IE over Firefox these days. wow have times changed !

Comment 65

[Sebastian Zartner [:sebo]]

This issue is marked as fixed for Firefox 28, so you just have to wait another 7 weeks[1] until it's working.

Sebastian

[1] https://wiki.mozilla.org/RapidRelease/Calendar

Comment 66

[Daniel Holbert [:dholbert]]

(In reply to Doug from comment #63)
> you guys have a good work-around for this?

If you have some fallback CSS for , you could paste relevant parts of that CSS into into a "@supports not (flex-wrap: wrap)" @-rule, per comment 19 / comment 21.

Comment 67

[Daniel Holbert [:dholbert]]

(sorry, edit fail -- meant to say "fallback CSS for [older browser-versions that lack any new-flexbox support]")

Comment 68

[Josh]

Registered here just for this post. Thank you Daniel for continuing to work on this, I really hope that you can consider the comments here and try to get this escalated. It might not seem super important but this functionality completely makes or breaks the flex spec for me. I have been trying to create a mobile responsive, horizontal scrolling blog type site where content always wraps to the next column if it overflows the height of its parent, giving it a classic, typographic look. This is a design that as far as I can tell has never been implemented properly. I have tried absolute positioning trickery, JS polyfills, css3 columns, floats, you name it and none of the methods have provided a reliable result. This is the light at the end of the tunnel for everyone frustrated with floats and clears and equal height columns. I agree I would like to hear more people are working on this instead of whatever other stuff is being prioritized. It somewhat disturbs me that this is working in every modern browser besides FF at this point. FF used to be my main browser and I have always associated it with forward thinking, current technology. This functionality, in my opinion, is going to completely change the rules of what front-end development can do, and how our sites can function. Amazing improvements to user experience, and mobile responsive! This is it!

Edit: Just read the comment above that this will be implemented within the week, amazing. Looking forward to this so much!

Comment 69

[Mjr Kusanagi]

I signed up to also post some angry comment about how this feature is critical to considering Mozilla a supported browser. But then I read @Josh's Edit, updated Firefox and frown literally turned upside down. Thanks for the excellent work Mr. @Daniel Holbert.

Comment 70

[thinsoldier]

@supports( flex-wrap:wrap ) seems to have stopped working recently in Nightly.

Comment 71

[thinsoldier]

Sorry. Ignore my last message. I was wrong.