23

What would be the right way to prefix this CSS in order to cover the widest range of browsers and versions?

Version 1:

-webkit-transition: -webkit-transform .3s ease-in-out;
   -moz-transition:    -moz-transform .3s ease-in-out;
    -ms-transition:     -ms-transform .3s ease-in-out;
     -o-transition:      -o-transform .3s ease-in-out;
        transition:         transform .3s ease-in-out;

 -webkit-transform: rotateX(-30deg);
    -moz-transform: rotateX(-30deg);
     -ms-transform: rotateX(-30deg);
      -o-transform: rotateX(-30deg);
         transform: rotateX(-30deg);

Or version 2:

-webkit-transition: transform .3s ease-in-out;
   -moz-transition: transform .3s ease-in-out;
    -ms-transition: transform .3s ease-in-out;
     -o-transition: transform .3s ease-in-out;
        transition  transform .3s ease-in-out;

 -webkit-transform: rotateX(-30deg);
    -moz-transform: rotateX(-30deg);
     -ms-transform: rotateX(-30deg);
      -o-transform: rotateX(-30deg);
         transform: rotateX(-30deg);

It appears to me that when using vendor prefixes on a transition property, I should also target the vendor prefixed attribute I want to transition.

I can't really find any closure to this.

TylerH
  • 20,799
  • 66
  • 75
  • 101
Jabba Da Hoot
  • 794
  • 2
  • 7
  • 16
  • this is just opinion based – Mr. Alien Apr 22 '15 at 19:15
  • @Mr.Alien: So you are saying it doesn't matter? – Jabba Da Hoot Apr 22 '15 at 19:16
  • 1
    @Mr.Alien I disagree. It seems to be a question of, "if i use vendor prefixes for the attribute, do i also need it for the property?" That can be objectively answered. – Scimonster Apr 22 '15 at 19:18
  • So you tried it, and the result was...??? I doubt that a browser that requires a prefixed version of `transform` (are there any?) would accept an un-prefixed version as the `transition` property, but what do I know, try it! –  Apr 22 '15 at 19:18
  • seriously either am missing some point or i dont see anything different about this – Mr. Alien Apr 22 '15 at 19:19
  • @MrAlien What is different is that one works, and one doesn't The question is, which one? –  Apr 22 '15 at 19:19
  • 1
    take a look at what Autoprefixer (https://github.com/postcss/autoprefixer) does – Felipe Skinner Apr 22 '15 at 19:20

3 Answers3

23

As I mentioned in a very similar question...

This is one of those cases where vendor prefixes for standardized features become extremely problematic, because you need to account for all the different prefixed and/or unprefixed implementations of different features in different versions of different browsers.

What a mouthful. And then you have to combine various permutations of these. What a handful.

In short, you need to figure out which versions of each browser requires a prefix for each of the individual properties, and unless you don't mind the bloat, you will need to apply the prefixes differently for individual browsers.

The linked question refers to animations rather than transitions which results in significantly different notations, but both features went through similar unprefixing processes AFAIK. That being said, here are the compatibility tables from caniuse.com for 2D transforms and transitions.

In other words, just because one feature is prefixed in one version of one browser doesn't mean the other feature is necessarily also prefixed in the same version of the same browser. For example, Chrome unprefixed transitions at least ten major versions (26) before it unprefixed transforms (36), and Safari still requires prefixes for transforms. As a result, you're definitely going to have to have this declaration:

transition: -webkit-transform .3s ease-in-out;

And if you absolutely need to, you will have to cover even older versions with the following:

-webkit-transition: -webkit-transform .3s ease-in-out;

Other browsers, miraculously, were able to unprefix both transitions and transforms (as well as animations) simultaneously, which makes things much easier:

  • -ms-transition is only used by pre-release versions of IE10, which have long since expired. No other version of IE uses prefixed transitions, so you should remove that particular transition prefix.

    -ms-transform with the prefix is only used by IE9; IE10 and later ship with unprefixed transforms. But for the purposes of graceful degradation you may want to keep your -ms-transform: rotateX(-30deg); declaration — just keep in mind that it cannot be transitioned as IE9 does not support CSS transitions or animations.

  • -moz-transition and -moz-transform were used by Firefox up to and including 15, then unprefixed in 16.

  • -o-transition and -o-transform were used by Opera up to and including 12.00, then unprefixed in 12.10, then re-prefixed as -webkit- in later versions in its move to Blink.

In summary, here are all the prefixes that you need, based on the information given by caniuse.com (which I trust to be current and accurate for the most part):

-webkit-transition: -webkit-transform .3s ease-in-out; /* Chrome < 26, Safari < 7 */
   -moz-transition:    -moz-transform .3s ease-in-out; /* Firefox < 16 */
     -o-transition:      -o-transform .3s ease-in-out; /* Opera < 12.10 */
        transition: -webkit-transform .3s ease-in-out; /* Chrome 26-35, Safari, Opera 15-23 */
        transition:         transform .3s ease-in-out; /* IE10+, Firefox 16+, Chrome 36+, Opera 12.10 */

 -webkit-transform: rotateX(-30deg);
    -moz-transform: rotateX(-30deg);
     -ms-transform: rotateX(-30deg); /* Only for graceful degradation in IE9, cannot be transitioned */
      -o-transform: rotateX(-30deg);
         transform: rotateX(-30deg);

The bare minimum that you will need to support the latest version of each browser as of this writing is:

        transition: -webkit-transform .3s ease-in-out; /* Chrome 26-35, Safari, Opera 15-23 */
        transition:         transform .3s ease-in-out; /* IE10+, Firefox 16+, Chrome 36+, Opera 12.10 */

 -webkit-transform: rotateX(-30deg);
         transform: rotateX(-30deg);

As mentioned in the comments, you can use a tool like Autoprefixer to automate this for you based on the level of browser support you require. However, for those who prefer to write their CSS manually, or for those who are just wondering exactly which prefixes are needed by which browsers, this is it.

On a final note: notice the two unprefixed transition declarations in the above examples? Now, you'd think it'd be easy enough to just combine them into a single declaration like this:

transition: -webkit-transform .3s ease-in-out, transform .3s ease-in-out;

But, unfortunately, Chrome will erroneously completely ignore this declaration, while other browsers will apply it just fine.

Community
  • 1
  • 1
BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
  • 1
    Great explanation! Thanks alot. It isn't as straightforward as most people think it is. – Jabba Da Hoot Apr 22 '15 at 19:41
  • @Wessel Grift: And I'm immensely grateful to you for posting this question for that reason. – BoltClock Apr 22 '15 at 19:43
  • Unfortunately, multiple unprefixed transition declarations result in the last declaration overriding the others wheather it's valid or not. Mentioned in [similar question](http://stackoverflow.com/questions/20669190/browser-specific-prefixes-with-a-css-transition-on-transform#answer-26147664). – tfE Mar 15 '17 at 11:47
  • @tfE: I'm a little lost. When you say "valid", do you mean "recognized"? As I mention not only here but also in the question you link to (*and* the other one that I link to in both places), a transition declaration is considered valid even if all of the properties listed are not recognized - so it *should* override all preceding properties, and that's by design. The problem is that in Safari (and Chrome until ca. 2014 - does Safari *still* suffer from this problem?), a transition declaration containing only unrecognized props is incorrectly considered invalid and therefore *does not* override. – BoltClock Mar 15 '17 at 12:40
  • Sorry, meant "recognized". In the linked question it's mentioned that: `transition: width 2s; transition: garbageProperty 2s;` "If you follow a transition rule with another transition rule (with the same prefixing or lack thereof), the first rule will be overwritten and no longer applied even if the second rule only has invalid properties listed on the right hand side." Tested in latest chrome, opera, firefox. The rule applies. So I figured your suggestion: – tfE Mar 15 '17 at 14:18
  • `transition: -webkit-transform .3s ease-in-out; /* Chrome 26-35, Safari, Opera 15-23 */ transition: transform .3s ease-in-out; /* IE10+, Firefox 16+, Chrome 36+, Opera 12.10 */` would end up with the first rule being disabled in such browsers. That was the concern I was talking about. But to my surprise both opera 22 and chrome 30 falled back to -webkit-transform. About ios: The only ipad I have and test on has ios 7.1 which came out in 2014. Once the bug with the combined unprefixed transition happens it falls back to -webkit-transition and too works fine. – tfE Mar 15 '17 at 14:19
  • 1
    @tfE: Good to know I knew exactly what I was doing then ;) – BoltClock Mar 15 '17 at 14:26
2

As of right now, if you’re supporting the top-two newest versions of each browser, here are the prefixes you need:

-webkit-transition: -webkit-transform .3s ease-in-out;
transition: transform .3s ease-in-out;

-webkit-transform: rotateX(-30deg);
transform: rotateX(-30deg);

So to answer your question, yes, the prefix-transition should target the prefix-transform. Pretty sure that is always true for transforms (although not necessarily for other properties. Flexbox and Gradients can be complex prefix-wise, I suggest you use Autoprefixer to keep those rules straight).

Also, my favorite way to figure out this kind of question is to go to a new Pen in CodePen, turn on Autoprefixer in the CSS settings, paste my code in, and compile it. Autoprefixer automatically adds prefixes for the top-two of each browser. Kinda magical!

Timothy Miller
  • 2,391
  • 1
  • 27
  • 34
  • @torazaburo it might not be, just depends on your browser support. The site I work on there are still quite a few people on old Android browsers, which do need -webkit- still, and it doesn't hurt anything to have them in there. But that's another reason I suggest Autoprefixer, automatically removes the prefixes once you don't need them anymore. – Timothy Miller Apr 22 '15 at 19:25
  • Thanks, pretty much what @BoltClock is saying. – Jabba Da Hoot Apr 22 '15 at 19:41
0

Ultimately, it's silly to make your web page load slower just to have support for older versions of auto-updating browsers. And, for IE, the ms prefix for animations is only used in pre-release versions. So, all any reasonable person needs is just support for webkiting transform for Safari.

transition: transform .3s ease-in-out;
/*you can put -webkit-transform below, but that will only waste space*/
transition: -webkit-transform .3s ease-in-out;

transform: rotateX(-30deg);
-webkit-transform: rotateX(-30deg);

And Voilà: it has same IE compatibility as having all those heavy prefixes while maintaining support for the latest version of auto-updating browsers. IF you really feel it is necessary to provide support to that .001% of people who keep on delaying their browser updates, then just put a little message at the bottom of the screen that tells the user to click the update button in their browser if the page doesn't display properly.

Jack G
  • 4,553
  • 2
  • 41
  • 50