13

The rub

  • CSS Tricks says that the order of the display vendor prefixes for flexbox is important and shows one ordering (-webkit-box, -moz-box, -ms-flexbox, -webkit-flex, flex)
  • MDN shows a different order than CSS Tricks and swaps -moz-box out for -moz-flex (-webkit-box, -webkit-flex, -moz-flex, -ms-flexbox, flex)
  • Bourbon shows yet a different order and brings in box, which the other two pages don't even mention (-webkit-box, -moz-box, box, -webkit-flex, -moz-flex, -ms-flexbox, flex)

The questions

  • Is order really important?
  • What is the correct way to do this?
Michael Benjamin
  • 346,931
  • 104
  • 581
  • 701
Hoagy Carmichael
  • 1,008
  • 7
  • 13

3 Answers3

15

As long as the W3C version (the official property) comes last, there is no difference.

The CSS rendering engine will always pick the last property that applies. Hence, you don't want Chrome, for example, to skip over flex and pick -webkit-flex, if flex is actually supported.

You're seeing variations in the ordering of vendor prefixes in CSS-Tricks, MDN and Bourbon because the order doesn't matter. Just note what they all have in common: flex is last.

Here are some more details:

Community
  • 1
  • 1
Michael Benjamin
  • 346,931
  • 104
  • 581
  • 701
  • If it's important that the official version comes last, I would also assume that it's important that the vendor-prefixed versions are in chronological order respective of themselves. For example, as long as `-webkit-box` is before `-webkit-flex`, and (independently) `-moz-box` is before `-moz-flex`. Is that correct? – Hoagy Carmichael Mar 25 '16 at 18:31
  • As illustrated in the examples posted in your question, the order of vendor prefixes is not significant. Make it easy on yourself, use this tool: [**autoprefixer**](https://autoprefixer.github.io/). – Michael Benjamin Mar 25 '16 at 18:37
  • 1
    I'm aware of the tool, but I think you've misunderstood me. I believe the order will be significant in a case such as this: If your browser understands `-prefix-box` and `-prefix-flexbox`, but not `-prefix-flex` or `flex`, if you have `-prefix-flexbox` before `-prefix-box`, you're going to get `-prefix-box` behavior (or so I assume). Hence, the order (independent of the other vendors) is significant. – Hoagy Carmichael Mar 25 '16 at 18:48
  • To play devil's advocate, taking your stance of vendor prefix not mattering all the way out, then why does the standard have to come at the end? If `-webkit-box` is just delegating to the same behavior as `flex`, it shouldn't matter, right? – Hoagy Carmichael Mar 25 '16 at 22:28
  • That's explained in the link references I posted in my answer. – Michael Benjamin Mar 25 '16 at 22:37
  • Well, the CSS Tricks link is a straw man. If one was using Webkit before it supported vanilla `border-radius`, you still would have had the wrong behavior. Multiple specs are supported for backwards-compatibility with sites that haven't updated to the unprefixed. You can add the CSS Tricks' `-webkit-border-radius` via inspector in up-to-date Chrome and it still works. – Hoagy Carmichael Mar 25 '16 at 22:48
  • 1
    Hoagy's correct that the `-webkit-box` vs. `-webkit-flex` ordering *is* significant. If you're using an old Chrome/Safari version that only support those prefixed keywords (and do not support unprefixed `flex`), they you'd absolutely want to prefer the more-modern `-webkit-flex` over `-webkit-box`. So, you should prefer listing `-webkit-flex` *after* `-webkit-box`. This is stillfollowing the general rule behind Michael's answer, though though: more modern stuff should come last, so that it "wins" over older stuff. – dholbert May 19 '16 at 15:59
  • I see what you're saying Hoagy and yes it makes sense. Thanks @dholbert for the explanation. – Michael Benjamin Jan 09 '17 at 03:59
5

Mostly, the order of the vendor prefixes aren't that important, but be sure that you are using the most standarized version by add the one without the vendor prefix (just flex) at the end. The CSS always prioritize the last if the properties are equal.

Anyway, the flex without prefixing is now supported by the most common browsers: http://caniuse.com/#feat=flexbox. 96% of the browsers can use flexbox, and 82% of them do support flex without prefixing.

NiklasMH
  • 697
  • 6
  • 16
  • Do you have any rationale for having the one that isn't vendor-qualified (`flex` in this case) as the last property? I've seen it parroted over and over to put it last, but have never seen any reasoning that wasn't superficial. – Hoagy Carmichael Mar 25 '16 at 22:41
  • Good question. I'm not an expert behind the scenes, but it seems more "natural" to place the property - which everyone are going to use in the end, as the last. But this is my knowledge, there could be some other reason why it is recommended. Maybe the vendor prefix does not get fixed equally later on - then if you still use the earlier version you won't get the global fix(?). Usually the global should be stable, but it was just a thought. – NiklasMH Mar 26 '16 at 01:36
4

I am adding a new proper answer. Because it does matter, especially for flexbox. And the last two examples you pointed out aren't up-to-date to today's required final syntax, and need to be discarded.

Like Niklas said, you always want the official W3C standard unprefixed property last. The reasoning is that CSS parses all rules one after another. The last rule of the same (or similar) property will always take precedence over a previous one. The case of flexbox is peculiar however, because of the 3 different types of rules and specs.

First, ignore the given MDN and Bourbon rule sets they are not up-to-date.

The rule display: -moz-flex; from the MDN example is sadly wrong. Firefox did (and does) not officially support it. Firefox officially only supports -moz-box or flex. I will have the article edited for corrections with the -moz-box substitution.

The box reference from Bourbon is no longer accurate. You do not need it. The reason some demos might include it, is that the official 'flexbox' standard property was to become box at the time (2009). flex did not exist at the point. The flex syntax came as final recommendation later in 2013.

And in between IE10 implemented the -ms-flexbox intermediate 2011-2012 draft spec.

So it's important for flex rule sets to declare older properties first, in the correctly given CSS Tricks order. You can find the rule set here, with additional explanations on full browser support.

The two rules that could be swapped either way without much effect are -webkit-box and -moz-box.

Note that Firefox and Edge have had to alias older properties, or the webkit prefixed rules, to try and solve various bugs occuring due to inaccurate order, and/or missing properties out there on the web.

So in that sense, using the full current flexbox rule set very much matters.

Community
  • 1
  • 1
hexalys
  • 5,177
  • 3
  • 31
  • 56