Related
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.
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.
You still (as of today) need the -webkit- prefix for Safari, on Mac OS X and iOS.
http://caniuse.com/#search=gradients
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.
I've got the following piece of code online:
background-image: -webkit-linear-gradient(left, rgba(0,0,0,0), rgba(0,0,0,0.75), rgba(0,0,0,0));
background-image: -moz-linear-gradient(left, rgba(0,0,0,0), rgba(0,0,0,0.75), rgba(0,0,0,0));
background-image: -ms-linear-gradient(left, rgba(0,0,0,0), rgba(0,0,0,0.75), rgba(0,0,0,0));
background-image: -o-linear-gradient(left, rgba(0,0,0,0), rgba(0,0,0,0.75), rgba(0,0,0,0));
Which works fine.
Now I'm no CSS-expert but I notice that all of those are prefixed. Is it wise to add a prefix-less version as well? What would it be?
Is it wise to add a prefix-less version as well?
Yes, you should always provide the un-prefixed version of any prefixed CSS code you use.
What would it be?
In the case of gradients, the version you have is the same as the standard; just drop the prefix.
But note that there was also an earlier variant of the webkit syntax for gradients, which you may also want to specify if you want to support older webkit browsers.
You should also include a plain colour background as a fallback for unsupported browsers.
If you're in any doubt about these things, consult sites like CanIUse or MDN.
If you want to get really cross-browser compatible, you may also note the IE9 and earlier do not support CSS gradients at all (with or without prefix). The plain colour fallback will work, but if you want a gradient there are alternative solutions (my preferred option is generally CSS3Pie, but there are pure CSS options if you prefer; they're not nice though).
The unprefixed, W3C standard, name is linear-gradient.
I am always using the Ultimate CSS Gradient Generator. It works just perfectly.
Your example would result in:
background: linear-gradient(to left, rgba(0,0,0,0) 0%,rgba(0,0,0,0.75) 50%,rgba(0,0,0,0) 100%);
To future proof the linear gradient just add at the end of your existing code this:
background-image: linear-gradient(left, rgba(0,0,0,0), rgba(0,0,0,0.75), rgba(0,0,0,0));
Like this when the browsers drop the prefix it will still be able to use the generic code.
I have a CSS stylesheet used in one of my web forms in an ASP.NET project.
I am working in Visual Studio 2008
Many times, when I make some change to it, it changes one of my CSS classes, resulting in some ugly borders.
For example: I make a change, save the stylesheet, continue working on some other page, then I notice the stylesheet needs to be saved again. I have to go back to the stylesheet, press Undo and then save it again.
I was curious about what changes, so I copied and compared the text before and after the undo, this is what changes:
EDIT: Right now, the moment I open the .css file by double clicking it in the solution explorer, it immidiately changes my css and needs to be saved. Extremely annoying.
What now follows is not my answer, but it is the best possible thing I could find, and now guess were I found it? Yes, right here in StackOverFlow
Here's the Link: Visual Studio (2012 and lower) deletes CSS properties
I really hope it helps
"
The existence of the "filter:" style is what's causing all of the "background-image:" styles to disappear except the last one listed. It's not that it's removing what it doesn't know, it's just removing all but the last "background-image" style listed. Must be Microsoft (intended) way of making filter and an MS specific background-image style play nicely together, however they didn't code it up very well. Definitely a MS VS defect. To repro, just right click in the CSS class that has code similar to this:
background-color: #EBEBEB; /* Fallback background color for non supported browsers */
background-image: -webkit-gradient(linear, left top, right top, from(#FFFFFF), to(#DAD6E7));
background-image: -webkit-linear-gradient(left, #FFFFFF, #DAD6E7);
background-image: -moz-linear-gradient(left, #FFFFFF, #DAD6E7);
background-image: -ms-linear-gradient(left, #FFFFFF, #DAD6E7);
background-image: -o-linear-gradient(left, #FFFFFF, #DAD6E7);
background-image: linear-gradient(left, #FFFFFF, #DAD6E7);
filter: progid:DXImageTransform.Microsoft.gradient(startCol
orStr='#FFFFFF', EndColorStr='#DAD6E7', gradientType='1'); /* IE6 - IE9 */
and then select "Build Style...". Then click "OK" without changing anything and watch it remove all but the last background-image left. Try changing the order of the "background-image styles and leave webkit last and then see for yourself.
You'll notice that if you remove the "filter:" style the problem goes away, however we need that (for this example) so the solution seems to be moving the "filter:" style above all the "background-image:" lines. Once you do that, it leaves them alone and the problem goes away.
Changing the above CSS to this seems to aleviate the problem:
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#FFFFFF', EndColorStr='#DAD6E7', gradientType='1'); /* IE6 - IE9 */
background-color: #EBEBEB; /* Fallback background color for non supported browsers */
background-image: -webkit-gradient(linear, left top, right top, from(#FFFFFF), to(#DAD6E7));
background-image: -webkit-linear-gradient(left, #FFFFFF, #DAD6E7);
background-image: -moz-linear-gradient(left, #FFFFFF, #DAD6E7);
background-image: -ms-linear-gradient(left, #FFFFFF, #DAD6E7);
background-image: -o-linear-gradient(left, #FFFFFF, #DAD6E7);
background-image: linear-gradient(left, #FFFFFF, #DAD6E7);
UPDATE: The workaround above only works for when VS applies formatting when you're using the "Build Style..." --> "Modify Style" dialog because I just saw it again with the fix above in place so it must be from somthing else.
"
Have you tried another Visual Studio version. Like 2010 or 2012.
Here the problem is that is reordering a few lines of code, but it seems here to be a problem from something else then Visual Studio. Try a reinstall. If you like VS style so much you could try a higher version. Advantages: A lot of bug fixed and lots of features added.
My recommendation: Try SublimeText2 for a while and see if you like it. I love it and it is a lot faster than VS. Give it a try. It worth.
I don't know your environment, so I can't say if something else is changing your CSS. If I were you, I would try opening the file with another editor, maybe two, just to find out if the blame is on Virtual Studio 2008.
If it turns out it is Virtual Studio's fault and you don't have an ultimate need to stick to using it, I would recommend Sublime Text. It's very powerful and it's free.
Try this:
From the toolbar,
Options->HTML Designer->CSS Styling, change "Auto Style Application" to "Manual Style Application"
In case anyone is as dense as me.
I had the same issue and it was because I had opened the css from the bin folder!
I am a web developer, I recently looked at GMAIL's new LOGIN PAGE preview and there is a Sign In button, I was really excited about its UI. I did some surgery of Page's CSS and found some properties like:
**background-color: #4D90FE;
background-image: -webkit-gradient(linear,left top,left bottom,from(#4d90fe),to(#4787ed));
background-image: -webkit-linear-gradient(top,#4d90fe,#4787ed);
background-image: -moz-linear-gradient(top,#4d90fe,#4787ed);
background-image: -ms-linear-gradient(top,#4d90fe,#4787ed);
background-image: -o-linear-gradient(top,#4d90fe,#4787ed);
background-image: linear-gradient(top,#4d90fe,#4787ed);**
Now can anyone please tell me how can I maximize the page's optimization for all popular browsers using these kind of CSS extension properties. I mean is there any reference link for these extensions or some other good stuff.
Thanks.
You should use google to find such information, a lot of it has been around since early 2010.
but here are some examples of browser specific gradient codes:
.gradient-bg {
/* fallback/image non-cover color */
background-color: #1a82f7;
/* fallback image */
background-image: url(images/fallback-gradient.png);
/* Safari 4+, Chrome 1-9 */
background-image: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#2F2727), to(#1a82f7));
/* Safari 5.1+, Mobile Safari, Chrome 10+ */
background-image: -webkit-linear-gradient(top, #2F2727, #1a82f7);
/* Firefox 3.6+ */
background-image: -moz-linear-gradient(top, #2F2727, #1a82f7);
/* Opera 11.10+ */
background-image: -o-linear-gradient(top, #2F2727, #1a82f7);
}
Taken from here.
To find out which browser supports which selector has a lot to with testing.
If you just need cross-browser-gradients, use http://www.colorzilla.com/gradient-editor/ (supports also IE6-9).
To find out, which technique is supported by which browser http://caniuse.com is a good resource.
There is a pretty comprehensive list of Mozilla's CSS extensions (or simply things that haven't been fully standardized yet) here: https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions
There is also an attempt to list all vendor-specific CSS properties under http://webdesign.about.com/od/css/a/css-extensions.htm but it is probably pretty incomplete and outdated - this area changes fast. In the end, you should better look at CSS3. Either a feature is already listed there which means that vendor prefixes will likely be dropped soon - or it is not and then using this feature in a production webpage isn't recommendable (its meaning might change significantly or browsers might stop supporting it altogether).
This is a list that I keep on me all times as a point of reference.
I hope this is of some use to you
http://qooxdoo.org/documentation/general/webkit_css_styles
I've got a number of CSS styles in my site's stylesheet that use the following, or variations of:
background: -webkit-gradient(
linear,
left bottom,
left top,
color-stop(0.0, #585858),
color-stop(1.0, #ACACAC)
);
background: -moz-linear-gradient(
center bottom,
#585858 0%,
#ACACAC 100%
);
My problem is that when it comes to validating the CSS using the W3C Validator, I get the following error:
Value Error : background -webkit-gradient(linear,left bottom,left top,color-stop(0.0,#585858),color-stop(1.0,#acacac)) is not a background value : -webkit-gradient(linear,left bottom,left top,color-stop(0.0,#585858),color-stop(1.0,#acacac)) -webkit-gradient(linear,left bottom,left top,color-stop(0.0,#585858),color-stop(1.0,#acacac))
As far as I'm aware, the CSS is fine...is this a problem with the validator I should make the testing team I work with aware of?
You are using vendor specific experimental implementations of CSS properties. They aren't valid CSS.
One of the options for the validator will allow you to downgrade vendor extensions from errors to warnings in the reports (so if you are choosing to use them on a production site you can find any errors that aren't related to using non-standard extensions).