Redundant Vendor Prefixes

Recently I had a great chance to attend a conference called AnEventApart. During one of the talks, I noticed an important quote said by Rachel Andrew (Expert to the W3C on the CSS Working Group and a Google Developer Expert):

Vendor Prefixes went away. Use them only when you need it.

The wording might be a little different, but the meaning is the same. This statement and my daily development work prompted me to write this article. The problem here is about redundancy. I took as an example CSS property transition and want to play with it. I’ll show you some examples of backward compatibility that I faced in my experience.

So, very often we tend to use this (or similar) structure:

-webkit-transition: .3s;
-moz-transition: .3s;
-ms-transition: .3s;
-o-transition: .3s;
transition: .3s;

Another way of doing this is to use SCSS/Less mixins:

SCSS:

@mixin transition($args...) {
    -webkit-transition: $args;
    -moz-transition:    $args;
    -ms-transition:     $args;
    -o-transition:      $args;
    transition:         $args;
}

LESS:

.transition ( ... ) {
    -webkit-transition: @arguments;
    -moz-transition:    @arguments;
    -ms-transition:     @arguments;
    -o-transition:      @arguments;
    transition:         @arguments;
}

But, let’s check the status of the current support for transition:

Boom! As we can see from caniuse table, transition has decent support. In this example, caniuse shows current and five previous versions of each browser and yes, this functionality can be used without prefixes. Even more: there are no vendor prefixes for transition in these browsers.

Moving forward

I really want to specify often used CSS properties divided into two groups: one group that should use prefixes and another that doesn’t need it. However, If I would do that I would be right only in one case: a group that doesn’t need prefixes. Because of the obvious reason: browsers are always updated and my first group will be always outdated. In addition to that, I found a good resource that might be helpful in this case: shouldiprefix.com

Conclusion

Use vendor prefixes only when you need them. When do you need them? Check on shouldiprefix.com