3

Usually when I make a gradient I use the colorzilla gradient edtior.

By default it generates the CSS for you. Here is an example:

background: #1e5799; /* Old browsers */
background: -moz-linear-gradient(top,  #1e5799 0%, #2989d8 50%, #207cca 51%, #7db9e8 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#1e5799), color-stop(50%,#2989d8), color-stop(51%,#207cca), color-stop(100%,#7db9e8)); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* IE10+ */
background: linear-gradient(to bottom,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* W3C */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#1e5799', endColorstr='#7db9e8',GradientType=0 ); /* IE6-9 */

While this is most certainly thorough, I'm curious if it is necessary. Through trial-and-error and process of elimination I have reduced it to the following CSS:

background: #1e5799; /* Old browsers */
background: linear-gradient(to bottom,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* W3C */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#1e5799', endColorstr='#7db9e8',GradientType=0 ); /* IE6-9 */

This reduced CSS still seems to function in Chrome, Firefox, IE8, IE9, and IE10, . However it's tough to say because using the Internet Explorer compatibility view doesn't always work very well (When I had IE9 my block worked, but after I upgraded to IE10 and used IE9 compatibility view it did not). I have also downloaded IETester and have had more success using this tool.

I was just curious if anyone could see if I was missing some vital CSS that might break in a given case or other important browser, or if maybe I could slim this down even more.

While not critical in importance, it makes quite the difference in size.

The difference between the two blocks is 618 bytes and in a sheet that uses 10 gradients, the difference is over 6 KB. As you can see this can add up fast (granted between caching and today's internet speeds it's not the most important factor) and I still think it's worth looking at.

Hanna
  • 10,315
  • 11
  • 56
  • 89
  • 1
    “in a sheet that uses 10 gradients, the difference is over 6 KB” — I bet it’s much smaller after gzipping though. Just taking your example code, I get 881 bytes vs. 268 without gzipping, and 341 bytes vs. 215 with gzipping. (On Mac OS X, I did `cat big.css | wc -c` on the command line to measure regular size, and `cat big.css | gzip -c | wc -c` to measure gzipped size.) – Paul D. Waite Jun 19 '13 at 21:45
  • gzip does very well at compressing text with lots of repetition in it. Including the same string in a file multiple times becomes almost free, size-wise, after gzipping. So having multiple gradient syntaxes really doesn’t hurt very much. (If your CSS *isn’t* being gzipped, making sure it *is* will do way more for your file size, with way less effort, than anything else.) – Paul D. Waite Jun 19 '13 at 21:48
  • 1
    IETester is not relevant. Use online tools like browsershot to test. The best is to keep IEs standalone on virtual machines for test. – G-Cyrillus Jun 19 '13 at 21:51
  • Is there an efficient tool for automating gzipping CSS on build or something similar? I work with a ton of spritesheets and tons of projects and doing this manually every time would be awful. – Hanna Jun 20 '13 at 06:09
  • @Johannes: depends on your build process. Gzipping itself isn't complicated: as you'll notice from my comment, I just used `gzip` on the Mac OS X command line to do it. Note that the web server needs to serve the file with a `Content-Encoding:gzip` header so that the browser knows it's gzipped. You can configure e.g. Apache to automatically compress files when it serves them. See e.g. http://stackoverflow.com/questions/12367858/how-can-i-get-apache-gzip-compression-to-work – Paul D. Waite Jun 20 '13 at 08:55

2 Answers2

2

Yeah, gradient syntax is a mess. Okay, here goes....

  • Firstly filter: IE9 is one you need to watch out for, especially if you're combining gradients with other CSS features.

    The old IE filter styles are based on ActiveX controls and are notoriously buggy, and this tends to be worse when they're combined with other browser features. IE9 introduced standard CSS syntax for most of the stuff that filter had previously been used for; gradients were about the only feature that didn't make it (certainly the only significant one).

    However those bugs in the ActiveX control for gradients seem to be even more obvious in IE9 than they were in IE8, largely due to the fact that it needs to interract with more built-in browser features than before. For example, filter gradients do not play nicely with border-radius. It completely kills the rounded corners. There are a number of other bugs you need to beware of too with filter styles.

    For this reason, many gradient tools will provide you with a whole alternative syntax for IE9, which involves creating an SVG gradient embedded as a data-url into the CSS background. It's not pretty but it does work better than filter for IE9, as it avoid all the filter bugs. Unfortunately for this technique, if you also need to support IE8, then the filter syntax is still needed; but you don't want it in IE9 to clash with the SVG style, which means CSS hacks or conditional comments or other such nastiness. Yep, it does all get a bit messy.

    Which is why my honest preferred solution is simply not to support gradients in IE8 or earlier. Too many issues, too much browser-specific code, and an ever-decreasing number of users to make it worth the effort.

    When I must support gradients in old IE, I use CSS3Pie, which is a polyfill script that adds support for the standard CSS gradient syntax. This means I can have my gradients in all IE versions without worrying about using a filter at all. (it uses VML to do the gradient behind the scenes, but you don't need to worry about the implementation details; just the end result).

  • The -ms- prefix: You're right. This is unnecessary, unless you plan to support the pre-release versions of IE10 (which of course is pointless as anyone using them would have upgraded to the real IE10 by now).

  • The two -webkit- syntaxes: This is because Webkit introduced the feature before the syntax had been finalised. Such is life on the bleeding edge. Although the syntax is now standardised, we still need to supply the old syntax because there are still a significant number of Safari and other webkit users on versions that use the old syntax. This will change over time, but it's not ready to be dropped yet.

  • The -o- prefix: This is for the Opera browser. It is only in the latest release that they dropped the need for the prefix. Any users not on the latest release will need it. It's your call as to how many users this might affect and therefore whether you can drop it or not. I'd say it's probably okay, as Opera users tend to keep their browser up-to-date.

  • The -moz- prefix: You can safely drop this now. Firefox hasn't needed the prefix since v16. There are very very few users on version earlier than that now. (even the Long Term Support version is FF17).

  • The plain-colour fallback: Keep this of course. Make sure your site looks okay with it (it doesn't have to look amazing; just okay). This is your insurance policy for users on old browsers. And yes, that may include people who have eg an old Firefox version that requires a prefix that you're not supporting.

So yes, the short answer is that you can drop a lot of it; not quite as much as you wanted to, but certainly some of it.

I'd write your code as follows:

background: #1e5799; /* Old browsers */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#1e5799), color-stop(50%,#2989d8), color-stop(51%,#207cca), color-stop(100%,#7db9e8)); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Chrome10+,Safari5.1+ */
-pie-background: linear-gradient(to bottom,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* IE6-9 with css3Pie */
background: linear-gradient(to bottom,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* W3C */
behavior: url(/PIE.htc); /* activate css3Pie in IE6-9 */

I've removed the -o- and -moz- prefixes and replaced the filter with CSS3Pie code (you'd obviously need to add PIE.htc to your site, but only IE will download it).

Hope that helps.

I also suggest looking at the CanIUse site for a full browser support chart.

Spudley
  • 166,037
  • 39
  • 233
  • 307
  • Re: Opera: I don't think it is correct that the prefix is dropped only in the latest release. Opera says it was needed untill Presto v2.10, which was introduced in Opera v.11.6 (more than one year ago). The browser has auto-update, so I wouldn't worry about older Opera versions – unless you are targetting a market which use Opera Mini (very popular some places) or Nintendo Browsers. I don't know which version of Presto they use, but signs point to Presto v.2.8 for Mini. – Nix Jun 20 '13 at 13:53
  • @Nix - I don't have an old copy of Opera to test against, but I was going on the data from CanIUse (see link above). If Opera themselves are saying otherwise, then clearly CanIUse is incorrect; someone needs to do some tests to confirm it and then post a correction on the CanIUse github. The good news is that if you're right, it makes dropping the `-o-` prefix an even easier decision than I was suggesting. Good news. – Spudley Jun 20 '13 at 13:58
  • I honestly don't see that info on caniuse. All I see, is that it is fully supported in 12.1. I believe the way it works, is that someone has simply confirmed that it works in 12.1, but not done specific testing on earlier versions. I think maybe I can find an older version of Opera, and create a Github issue if needed. – Nix Jun 20 '13 at 14:03
  • @Nix: click on “Show all versions” in the top-left corner of [their compatibility table](http://caniuse.com/#search=gradients). – Paul D. Waite Jun 20 '13 at 14:19
  • @Spudley: I see what you mean about IE 8, but if you are supporting it, I would have thought you’d want to use the “add an IE class to the `` element using conditional comments” trick anyway, and you could thus use your IE8 class to avoid applying the `filter` to IE 9. I’d pick `filter`over a separate .htc file anyday, seems like fewer moving parts. – Paul D. Waite Jun 20 '13 at 14:22
  • @Nix - I can definitely see the info there; CanIUse shows a `-o-` on 11.6 and 12.0. You're saying it shouldn't be there. But anyway, we're arguing about a small point; whatever the facts in that, we can agree that for most devs it's a reasonable option to drop the `-o-` prefix for gradients. – Spudley Jun 20 '13 at 14:23
  • @PaulD.Waite - re an ie8 class on ``; yes, that's kinda what I meant by using conditional comments. And as for filter vs htc... well, yeah, fewer moving parts, but in my experience more bugs. (can you tell I've been bitten by `filter` bugs more than once? ;-)). Mind you, Pie has issues of its own too, so I guess it's swings and roundabouts. – Spudley Jun 20 '13 at 14:31
  • @Spudley: well indeed. Conditional comments have always seemed to safest approach to me - they're explicit, designed for the purpose at hand, and supported by Microsoft. `filter` definitely has its issues, involving both those .htc files and VML seemed like one too many obscure extra bits to me. As you say, swings and roundabouts. – Paul D. Waite Jun 20 '13 at 14:44
  • Thanks for this wealth of information Spudley, it is greatly appreciated! As discussed in the comments, I too would probably opt for conditional statements over CSS3Pie but it's a nice suggestion. – Hanna Jun 20 '13 at 15:48
1

You still (as of today) need the -webkit- prefix for Safari, on Mac OS X and iOS.

You also need the -moz-- and -webkit--prefixed versions for older versions of Firefox and Chrome.

“Aha,” you say, “but those browsers auto-update now!”

“Why yes,” I reply, wearing a patient smile, “but not on old Android phones they don’t.”

-ms-linear-gradient wasn’t ever supported though (IE 9 didn’t support CSS gradients, just filter and SVG backgrounds, and IE 10 supports linear-gradient), so you can drop that. (And if you can find anyone still using Opera, you can ask them how they feel about gradients.)

However, as I commented: once your CSS is gzipped, the additional gradient declarations don’t take up much extra space. Obviously it’s up to you to balance the size difference against the browsers you want to support, but I’d suggest you judge based on size after gzipping, and (if possible) based on the browsers your audience (and intended audience) are actually using.

Paul D. Waite
  • 96,640
  • 56
  • 199
  • 270
  • Very insightful. It's nice to be reminded that browsers don't auto-update on mobile, though I don't need to worry about that at the moment as my application isn't meant for mobile and is incompatible with it. When such a time comes where I need to make a mobile friendly version this is good to keep in mind. The reason I mentioned the browsers I did was because those are the ones the clients use, but I should still consider Safari. – Hanna Jun 20 '13 at 06:14
  • @Johannes: yeah, obviously the worst case is that users of browsers that don't support gradients get the flat background colour, which isn't the end of the world. There may be some browsers that auto-update on mobile, and Apple likes to brag about the high percentage of iOS users using the latest version. – Paul D. Waite Jun 20 '13 at 08:57
  • "And if you can find anyone still using Opera, you can ask them how they feel about gradients." Opera use the standard; it does not need the -o prefix. – Nix Jun 20 '13 at 13:01
  • @Nix: which version? caniuse.com says it required the `-o-` prefix until 12.1. – Paul D. Waite Jun 20 '13 at 13:04
  • @PaulD.Waite I don't think that is correct. Opera says it was needed untill Presto v2.10, which was introduced in Opera v.11.6 (more than one year ago). The browser has auto-update, so I wouldn't worry about older Opera versions – unless you are targetting a market which use Opera Mini (very popular some places) or Nintendo Browsers. I don't know which version of Presto they use. – Nix Jun 20 '13 at 13:36
  • @Nix: could you link to a source for that statement from Opera? – Paul D. Waite Jun 20 '13 at 14:18
  • 1
    @PaulD.Waite I was looking at the [Opera product specs](http://www.opera.com/docs/specs/productspecs/), which state that a) **Up until Presto 2.10, Gradients in Opera use the -o- vendor prefix.** and b) **Opera Desktop 11.60 runs on the Presto 2.10 rendering engine.**. However, I find a lot of other sources saying that it was indeed not removed until Opera 12.1. Either I am reading the specs wrong, the specs themselves are incorrect, or other people are citing an incorrect source. – Nix Jun 20 '13 at 21:33
  • Either way, Opera autoupdates and there are few old versions in the wild, so I think it's safe to remove the prefix. – Nix Jun 20 '13 at 21:35
  • @Nix: excellent, cheers for the source. Yeah I remember seeing a couple of things in Opera's documentation that haven't actually been true. I'd recommend looking at the stats for whatever website you're working on before making a decision about dropping old Opera versions, but it's never been super-popular (though its users can be quite vocal). – Paul D. Waite Jun 21 '13 at 08:18