Making and Breaking the Web With CSS Gradients

What is CSS prefixing and why do I care?

Straight from the source:

“Browser vendors sometimes add prefixes to experimental or nonstandard CSS properties, so developers can experiment but changes in browser behavior don’t break the code during the standards process. Developers should wait to include the unprefixed property until browser behavior is standardized.”

As a Web developer, users of your web sites will be affected if you use prefixed CSS properties which later have their prefixes removed—especially if syntax has changed between prefixed and unprefixed variants.

There are steps you can take in stewardship of an unbroken Web. Begin by checking your stylesheets for outdated gradient syntax and updating with an unprefixed modern equivalent. But first, let’s take a closer look at the issue.

What are CSS gradients?

CSS gradients are a type of CSS <image> function (expressed as a property value) that enable developers to style the background of block-level elements to have variations in color instead of just a solid color. The MDN documentation on gradients gives an overview of the various gradient types and how to use them. As always, CSS Tricks has top notch coverage on CSS3 gradients as well.

Screenshot of bloomberg.com's CSS with a CSS gradient

Removing (and then not removing) prefixed gradients from Firefox

In Bug 1176496, we tried to remove support for the old -moz- prefixed linear and radial gradients. Unfortunately, we soon realized that it broke the Web for enough sites ([1], [2], [3], [4], [5], [6]) that we had to add back support (for now).

Sin and syntax

Due to changes in the spec between the -moz- prefixed implementation and the modern, prefix-less version, it’s not possible to just remove prefixes and get working gradients.

Here’s a simple example of how the syntax has changed (for linear-gradient):

/* The old syntax, deprecated and prefixed, for old browsers */
background: -prefix-linear-gradient(top, blue, white); 
/* The new syntax needed by standard-compliant browsers (Opera 12.1,
   IE 10, Firefox 16, Chrome 26, Safari 6.1), without prefix */
background: linear-gradient(to bottom, blue, white);

In a nutshell, to and at keywords were added, contain and cover keywords were removed, and the angle coordinate system was changed to be more consistent with other parts of the platform.

When IE10 came out with support for prefixless new gradients, IEBlog wrote an awesome post illustrating the differences between the prefixed (old) syntax and the new syntax; check that out for more in-depth coverage. The css-tricks.com article on CSS3 gradients also has a good overview on the history of CSS gradients and its syntaxes (see “Tweener” and “New” in the “Browser Support/Prefixes” section).

OK, so like, what should I do?

You can start checking your stylesheets for outdated gradient syntax and making sure to have an unprefixed modern equivalent.

Here are some tools and libraries that can help you maintain modern, up-to-date, prefixless CSS:

If you’re already using the PostCSS plugin Autoprefixer, you won’t have to do anything. If you’re not using it yet, consider adding it to your tool belt. And if you prefer a client-side solution, Lea Verou’s prefix-free.js is another great option.

In addition, the web app Colorzilla will allow you to enter your old CSS gradient syntax to get a quick conversion to the modern prefixless conversion.

Masatoshi Kimura has added a preference that can be used to turn off support for the old -moz- prefixed gradients, giving developers an easy way to visually test for broken gradients. Set layout.css.prefixes.gradients to false (from about:config) in Nightly. This pref should ship in Firefox 42.

Modernizing your CSS

And as long as you’re in the middle of editing your stylesheets, now would be a good time to check the rest of them for overall freshness. Flexbox is an area that is particularly troublesome and in need of unbreaking, but good resources exist to ease the pain. CSS border-image is also an area that had changes between prefixed and unprefixed versions.

Thanks for your help in building and maintaining a Web that works.

About Mike Taylor

Mike works as a Web Compatibility Engineer for Mozilla from his home in Austin, TX.

More articles by Mike Taylor…

About Dietrich Ayala

More articles by Dietrich Ayala…


3 comments

  1. Colin Eberhardt

    just playing devils advocate here …

    Considering the issues that occurred when you tried to withdraw a prefix, can you ever realistically consider repeating this exercise? For every broken site you were made aware of, there were probably thousands of low-profile sites that you were not aware of.

    With that in mind, is there any point in people changing the CSS on an already working website? Either manually, or by running a build with an updated prefixed? Unless everyone does this, you’re breaking the web!

    Anyhow, like I said, mostly just playing devils advocate!

    August 6th, 2015 at 23:57

    1. Andy Mercer

      Colin, if a site is broken by a browser removing support for an old, prefixed implementation, then that site isn’t worth caring about. Prefixed styles are experimental, and shouldn’t be used in production. Lots of developers decided to abuse the situation and use those prefixed styles, its true. But we shouldn’t hold back progress to cater to those individuals. Site breakage doesnt matter, if its the fault of the web developer.

      August 16th, 2015 at 11:08

  2. Mike Taylor

    Good points Colin.

    > With that in mind, is there any point in people changing the CSS on an already working website?

    Well, it means we *might* have a chance of being able to remove support for the old prefixed CSS properties. You’re right that there are unknowns and it may never be possible. But if people are willing (and able) to update their code I think that’s a good thing™.

    August 7th, 2015 at 09:25

Comments are closed for this article.