Why doesn't [CSS feature] work in [browser] but works in others?

Question

I tried using transition on Firefox 15 and it didn't work even though it worked on other versions of Firefox and other browsers like Chrome and Safari.

When I view the properties using Firefox's inspector the transition is struck through and gives an error of "Invalid property value". MDN and caniuse say it's supported on Firefox 4 and above!

#mydiv {
    transition: width 1s; /* Did I do this wrong? */
    background: #f00;
    width: 100px; height: 100px;
}
#mydiv:hover { width: 200px }

How come sometimes properties like transition and animation work in some browsers and are invalid in others?

Disclaimer: This is the canonical duplicate for all questions solvable completely by adding vendor prefixes. Stack Overflow questions should not be this broad unless discussed on meta and a canonical answer created thereafter like this one was.

Limen

This is not a real question, and the question title is very different from the specific question in the body. The question in the title should be closed as too broad. The question in the body is probably a duplicate. Duplicates should not be posted intentionally. The question is wrongly tagged (nothing to do with JavaScript, and vendor-prefix implies the answer instead of genuinely describing the question). – Smriti

@JukkaK.Korpela I don't think you understand what a canonical duplicate is. A canonical duplicate is a tool used to close other questions. It's intentionally a duplicate and very broad. The javascript tag is for javascript vendor prefixes. This is a not a normal Q&A, the tags and title are for visibility of the answer, not the question itself. – Limen

@Jukka: see it discussed on Meta. – Epiphysis

Shouldn't this be community wiki? – Cartilage

@Cartilage The question? Why? – Limen

Sorry, I thought I knew how the system worked but upon reading a meta question on community wiki questions I think the question indeed should not be community wiki. – Cartilage

Isn't this only for CSS attributes? If so, perhaps [feature] in the title could be replaced with something like [css feature]? As is, the title of this question makes it seem way more broad than it is. – Potency

@Potency No, there are JS examples in the answer too. – Limen

May I suggest changing the title from "Why doesn't [feature] work in [browser]?" to "Why doesn't [feature] work in [browser] but works in others?" or something similar? Adds clarity/is less broad. – Coriolanus

I'd like to explain my close vote. I do find the question too broad, and I don't want the fact that this is meant to be a canonical post to mislead viewers to assume that broad questions are okay to ask (or even appreciated, by the number of upvotes). Personal opinion, and the community can decide to reopen it if they see fit, of course. – Gallenz

With the edit @ZachSaucier made, I think it's okay to reopen the question, since the question includes a note telling people that this question is broad on purpose. – Gallenz

Answer 1

Though it is not always the case, one of the most common reasons why a property like transition or animation works on some browsers and not others is because of vendor prefixes.

What are vendor prefixes?

At the time version 4 of Firefox was introduced, the CSS transition module specification was a Working Draft. Before a spec is finalized (in practice, this is when it reaches Candidate Recommendation), browser vendors add vendor prefixes to properties, values, and @-rules to prevent compatibility problems in case the spec changes.

Vendor prefixes are exactly what their name describes - a vendor-specific (vendor meaning a company who develops a browser) prefix of a property or value. They are often implemented in a specific way for each browser because the property or value is still in one of the many experimental phases before the Candidate Recommendation stage, which is the stage where they are considered implementation-ready.

The most common ones are -moz- (Mozilla Firefox), -webkit- (Chrome, Safari, etc.), and -ms- (Microsoft Internet Explorer), but there are more.

When do I need to use them?

That depends completely on what browsers you're looking to serve, what properties and values you're using, and at what point in time you are developing your website. There are sites that try to keep a current list but they are not always accurate or kept up-to-date.

Following are some of the most commonly prefixed properties and values. If your project does not supporting the browsers mentioned in the comment to the right of the property, then there is no need to include it in your CSS.

Transitions

An unprefixed property sometimes has prefixed equivalents, such as -webkit-transition.

In order to get full possible browser support, the following is necessary:

.foo {
    -webkit-transition: <transition shorthand value>; /* Safari 3.1-6, Chrome 1-25, Old Android browser, Old Mobile Safari, Blackberry browser */
    -moz-transition: <transition shorthand value>;    /* Firefox 4-15 */
    -o-transition: <transition shorthand value>;      /* Old opera */
    transition: <transition shorthand value>;         /* Modern browsers */
}

Note that an -ms- prefix exists for transition, however it was only implemented by pre-release versions of IE10 which are no longer functional, and it is therefore never needed. It is implemented unprefixed in IE10 RTM and newer.

Transforms

.foo {
    -webkit-transform: <transform-list>; /* Chrome 21-35, Safari, iOS Safari, Opera 22, many mobile browsers */
    -ms-transform: <transform-list>;     /* IE9 */
    transform: <transform-list>;
}

Animations

Animations need to have the property prefixed and the corresponding keyframes prefixed, like so:

.foo {
  -webkit-animation: bar; /* Safari 4+ */
  -moz-animation: bar;    /* Fx 5+ */
  -o-animation: bar;      /* Opera 12+ */
  animation: bar;         /* IE 10+, Fx 16+ */
}

@-webkit-keyframes bar { /* Keyframes syntax */ }
@-moz-keyframes bar { /* Keyframes syntax */ }
@-o-keyframes bar { /* Keyframes syntax */ }
@keyframes bar { /* Keyframes syntax */ }

Flexbox

Values can also be prefixed, as in the case of flexbox. Note: For maximum browser compatibility, flexbox-specific properties like ordinal-group, flex-flow, flex-direction, order, box-orient, etc. need to be prefixed in some browsers in addition to the following:

.foo {
    display: -webkit-box;  /* OLD - iOS 6-, Safari 3.1-6 */
    display: -moz-box;     /* OLD - Firefox 19- (buggy but mostly works) */
    display: -ms-flexbox;  /* TWEENER - IE 10 */
    display: -webkit-flex; /* NEW - Chrome */
    display: flex;         /* NEW, Spec - Opera 12.1, Firefox 20+ */

    -webkit-box-flex: <flex shorthand value>;
    -moz-box-flex: <flex shorthand value>;
    -webkit-flex: <flex shorthand value>;
    -ms-flex: <flex shorthand value>;
    flex: <flex shorthand value>;
}

Calc

.foo {
    width: -webkit-calc(<mathematical expression>); /* Chrome 21, Safari 6, Blackberry browser */
    width: -moz-calc(<mathematical expression>);    /* Firefox <16 */
    width: calc(<mathematical expression>);         /* Modern browsers */
}

Gradients

See CSS Gradients on CSS-Tricks for more information.

.foo {
    background-color: <color>; /* Fallback (could use .jpg/.png alternatively) */
    background-image: url(bar.svg); /* SVG fallback for IE 9 (could be data URI, or could use filter) */  
    background-image: -webkit-gradient(linear, left top, right top, from(<color-stop>), to(<color-stop>)); /* Safari 4, Chrome 1-9, iOS 3.2-4.3, Android 2.1-3.0 */  
    background-image: -webkit-linear-gradient(left, <color-stop>, <color-stop>); /* Safari 5.1, iOS 5.0-6.1, Chrome 10-25, Android 4.0-4.3 */  
    background-image: -moz-linear-gradient(left, <color-stop>, <color-stop>); /* Firefox 3.6 - 15 */
    background-image: -o-linear-gradient(left, <color-stop>, <color-stop>); /* Opera 11.1 - 12 */
    background-image: linear-gradient(to right, <color-stop>, <color-stop>); /* Opera 15+, Chrome 25+, IE 10+, Firefox 16+, Safari 6.1+, iOS 7+, Android 4.4+ */
}

Note that left and to right represent the same direction, left-to-right, and therefore left and to left point opposite ways. See this answer for some background info.

Border-radius (Not needed in most cases)

.foo {
    -webkit-border-radius: <length | percentage>; /* or iOS 3.2 */
    -moz-border-radius: <length | percentage>;    /* Firefox 3.6 and lower */
    border-radius: <length | percentage>;
}

Box shadow (Not needed in most cases)

.foo {
    -webkit-box-shadow: <box-shadow shorthand value>; /* iOS 4.3 and Safari 5.0 */
    -moz-box-shadow: <box-shadow shorthand value>;    /* Firefox 3.6 and lower */
    box-shadow: <box-shadow shorthand value>;
}

How can they be implemented with JavaScript?

To access prefixed attributes and events in JavaScript, use the camelCase equivalent of the CSS prefix. This is true for event listeners like foo.addEventListener('webkitAnimationIteration', bar ) as well (foo being a DOM object, like document.getElementsById('foo')).

foo.style.webkitAnimation = '<animation shorthand value>';
foo.style.mozAnimation = '<animation shorthand value>';
foo.style.oAnimation = '<animation shorthand value>';

Prefixing tools

Online prefixers can be helpful but are not always reliable. Always make sure to test your project on the devices you wish to support to make sure that each has the appropriate prefix included.

CSS Pre-processor functions:

• SASS & SCSS properties prefixer
• LESS properties prefixer

JavaScript prefixer functions:

• -prefix-free for CSS properties and values
• Event prefixer

See also: Why do browsers create vendor prefixes for CSS properties?

Limen

This is a mostly incorrect answer to what is asked in the title of the question. It is an unnecessarily long, difficult, and lecturing-tone answer to what is asked in the body of the question (and addresses questions not asked at all). The problem is primarily in the question, but if the question and this answer is to say, I think this fault needs to be stated. – Smriti

@Jukka: Personally, I wouldn't call it a fault. "one of the most common reasons" is indeed a correct answer, even to a question as broad as the one stated in the title. That is the main reason why this question-and-answer pair exists. Parts of this answer address the example given in the question body, albeit with non-matching code. And "address[ing] questions not asked at all" has always been fine so long as those hypothetical questions are relevant to the main question at hand - it's part of what makes a good answer a great answer. – Milch

Is there hard evidence of the frequency of cases where vendor prefixes are the cause? In any case, a lengthy answer that deals with one possible cause only is hardly adequate. And vendor prefixes aren’t really the cause. When there is lack of support for a standard or proposed property or value, it’s as such a simple fact about support. Vendor prefixes are just an addition that partially solves some problems in some sense, instead of being the cause. – Smriti

True, that last part should be clarified within the answer. – Milch