I've got this SCSS code:
.gradient-text {
color: mix(#cea427, #fbe758); // Fallback to average of 2 colors
background: -webkit-linear-gradient(0deg, #cea427, #fbe758);
-webkit-background-clip: text;
-webkit-text-fill-color: transparent;
}
Fiddle
At first I just wanted to make this code work in webkit-based browsers and then add different approach for firefox, but I've found out that at least latest nightly firefox runs this code too, even if it's vendor-prefixed for webkit.
I won't worry if there was only one property, which can be either supported by firefox or not. But having 2 properties makes me nervous about the situation where only one of them is working. For example, supported -webkit-linear-gradient and unsupported -webkit-background-clip will work vastly different from my expectations. So, is there any way I can check browser support for multiple CSS rules and gracefylly switch to fallback if at least one of them is missing?
And also, is there any list of foreign vendor prefixes support (like -webkit- prefix support in FF)?
In these sort of situations, I always find it very helpful to check MDN. In this case, you can check the articles for linear-gradient, background-clip and -webkit-text-fill-color. Near the bottom, there is always a section titled Browser compatibility. It lists, in a table, browsers that support the CSS rules and in footnotes goes into specifics. For example, about the -webkit-text-fill-color, it says that
[1] This feature is implemented behind the preference layout.css.prefixes.webkit, defaulting to false. Since Gecko 49 (Firefox 49.0 / Thunderbird 49.0 / SeaMonkey 2.46) the preference defaults to true.
This should answer your question on why the -webkit- prefixed version is supported, and since when. Also note that at the top, the article mentions
This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.
So: ye be warned.
In this particular case, you might be able to get away with what you want to do, at least in Firefox and Chrome. Other browsers... that's trickier.
Your other question is if you can gracefully switch to a fallback when a rule is not supported. Unfortunately, this is not possible in pure CSS. It is possible to write rules that specifically target Chrome or Firefox though, but I would advise against using those. You could maybe check for support using JavaScript, but that is something I wholeheartedly advise against.
Finally, "is there any list of foreign vendor prefixes support (like -webkit- prefix support in FF)?" Sort of. Again, MDN is usually very complete and up-to-date. Hope that helps.
Related
For a mobile site, do I really need to specify both prefixed and non-prefixed CSS property names?
For example:
-webkit-background-size:1em; /* absolutely mandatory */
background-size:1em; /* a useless redundancy */
Is there any mobile browser whatsoever that will ignore -webkit properties and only consider the non-prefixed ones? I want to get rid of all non-prefixed attributes to shorten and clear the CSS code.
PS: most phones in third world countries sold with Android 4.1 don't even parse the non-prefixed properties, they still require the -webkit prefix. Another reason to remove the non-prefixed ones.
I don’t know of any resource that tracks support of CSS properties in all mobile browsers (there are a lot of mobile browsers), so it’s difficult to confirm whether there’s any browser that no longer supports the prefixed versions.
I would note that, specifically regarding background-size, it looks like support for the non-prefixed versions came in pretty quickly, and that there aren’t many browsers that required the prefix: http://caniuse.com/#search=background-size.
The current idea is that at some point in the future, support for the prefixed versions of the properties will be dropped. See, for example, this WebKit mailing list post from May 2013:
We will continue to support the prefixed properties for some amount of time, decided on a case-by-case basis.
https://lists.webkit.org/pipermail/webkit-dev/2013-May/024850.html
It may be a long time before this happens, or it may never happen. But as time goes on, the probability of it happening increases, and the number of people still using browsers that require the prefixed versions goes down.
Given that by removing the *non-*prefixed versions you’ll only be removing one line, it doesn’t seem to me like a big gain in shortness or clarity in exchange for the potential future breakage.
I’d suggest initially writing your CSS without the prefixed versions, then looking at the browser stats for your site to see which prefixed versions you really need. For some prefixed features (e.g. gradients), maybe older browsers can live without them.
The redundancy in this case is not useless. Older mobile browsers that don't support the standard background-size but that do support -webkit-background-size will still render. Newer versions of the browser will likely deprecate the -webkit prefixed property but will support both the prefixed property value -webkit-background-size and the non-prefixed standardized property background-size. In this case, the last value specified will be the value used so yes the mobile browser will ignore the -webkit prefixed property in favor of the standardized property.
Be mindful that future browsers will probably remove deprecated values. In this case the prefixed property would no longer be supported and the site's styles would break. To ensure, current and future functionality it is a good idea to use both versions for now. When you no longer need to support older versions of the browser, you should drop the prefixed version in favor of the non-prefixed standardized version. The non-prefixed property is the CSS standard and should never be dropped in favor of the vendor specific prefixed property.
I have a website which I support as far as IE8, no further.
When I first launched the site, I decided to use CSS vendor prefixes for CSSs elements such as border-radius, box-shadow etc. I did this from a complete noob standpoint.
However, is a better approach not to use them and simply let browsers catch up rather than patch up for the sake of uniformity?
No, you shouldn't remove all of them, however you may as well remove the ones which are no longer required.
How can I find out which prefixes are no longer required?
Can I use... is a great resource for checking browser support for various CSS, HTML and JavaScript features. If you perform a search for box-sizing, for instance, it will tell you that all modern browsers have partial support for this and that Firefox requires the -moz- prefix. You can also view all of the CSS support tables on just one page here.
How can I clarify that the prefixes are no longer required?
There are a couple of online resources which display information about browser usage. An example of this is StatCounter. StatCounter offers browser version statistics which can be filtered on time. If we look at the last 3 months, we can guestimate that we should still aim to support Firefox 20+, Chrome 25+, IE 8+ and Safari 5.1+.
Personally, I would just keep your vendor prefixes for now - this still remains professional practice - those browsers who don't need them, will simply ignore them anyway.
Our approach is to drop those which aren't needed.
border-radius
box-shadow
box-sizing (soon? firefox still uses it. Noted by #James Donnelly)
opacity (not a prefix, but no need for the ms-filter thingie)
inline-block (same here, no need for inline+zoom fix)
If you really want to get rid of prefixes, one of the solutions you can try is -prefix-free. It's a javascript plugin which loops through your stylesheets and, according to current browser removes the unused ones.
Although I didn't test it, I think it will definetely lower the performance.
You can also remove prefixes for properties which doesn't have a signifact meaning for functionality and/or user experience, like border-radius, box-shadow etc. You would have to test each element how it behaves without these properties. E.g. you have a button with border-radius: 4px. In a browser which doesn't support border-radius it will simply have rough corners. You must only consider if its worth sacrificing.
As I'm sure you all know, Internet Explorer can handle simple gradients. Here is a snippet from Twitter Bootstrap, for example:
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffff', endColorstr='#e6e6e6', GradientType=0);
However, I've seen some people use two CSS rules (one for IE < 8 and one for IE 8), like so:
filter:progid:DXImageTransform.Microsoft.gradient(GradientType=0, startColorstr='#7fbf4d', endColorstr='#63a62f'); /* For Internet Explorer 5.5 - 7 */
-ms-filter: "progid:DXImageTransform.Microsoft.gradient(GradientType=0, startColorstr='#7fbf4d', endColorstr='#63a62f')"; /* For Internet Explorer 8 */
My question is, is the second rule really necessary? Twitter Bootstrap is quite thorough, yet it doesn't use any "-ms-filter" rules. According to this page, the -ms-filter attribute is an extension to CSS, and can be used as a synonym for filter in IE8 Standards mode.
My suggestion:
Use CSS3Pie -- http://css3pie.com/
This is a JavaScript library for IE6, IE7 and IE8 that patches in support for several CSS3 features, including gradients.
Yes, you can use the horrible IE-specific filter styles if you want, but CSS3Pie allows you to use standard CSS styles for these features. Much easier.
To actually answer your direct question:
Yes, the -ms-filter style is usually required. IE8 will always us it instead of filter, which is used primarily for IE6 and IE7. In some cases filter will work in IE8, but not all, so it's best to use -ms-filter to ensure IE8 compatibility.
[EDITED]
Why did they change it? Because when they released IE8, Microsoft made a big point of trying to be "standards compliant".
For a browser to be standard-compliant, it should use a vendor prefix for any CSS property it supports that is not a finalized W3C standard. So by adding the -ms- prefix, Microsoft were trying to (belatedly) undo their pollution of the global CSS namespace.
In addition, the quotes were added, because the old filter syntax without the quotes was invalid CSS (mainly because of the colon after progid), and caused issues with some browsers. (I had an instance some time ago with Firefox 3.6 where it was dropping all styles following a filter style that rotated an element - took ages to work out what was happening).
The fact that Microsoft retained backward compatibility with the original filter syntax, was largely a matter of pragmatism. MS couldn't afford to break all the sites using the old syntax. But there was a strong implication from Microsoft that developers should use both because they would drop support for the old filter style in subsequent versions of IE. As it turned out, they dropped support for both filter and -ms-filer in one fell swoop, but the implications given at the release of IE8 were sufficient for it to become recommended practice to provide both syntaxes in your stylesheet.
At the time when IE8 was released, XHTML was the new flavor of the month, and writing code that validated perfectly was top of the list for a lot of developers. This was probably a strong driving force in the change of syntax to include the quotes. Because of the stray colons, it is impossible to write CSS that validates using the old filter style. Using the new -ms-filter styles instead allowed people to write valid CSS. As good ideas go, this one didn't really work out because of course people had to keep using the old syntax anyway, but the intent was good.
It's worth pointing out that other proprietary styles were given the same treatment. For example, you can use -ms-behavior in IE8 instead of the old behavior style. No-one uses it. Why? I don't really know.
Another fact worth knowing is that the W3C are in the process of standardizing a CSS property called filter. It will do a completely different job to the Microsoft filter style, and work completely differently. If/when it is standardized and browsers start supporting it, there will be an explicit clash between the two syntaxes.
Seems like you answered your own question. Yes they're needed. Microsoft trying to get more in line with the standards means that some versions of IE have their own slightly different syntax rules for the filter property.
In IE7 just filter: followed by the progid:DXIma... etc will work. But for IE8+ there is the IE7 fallback it may use in compatibility mode, and the more proper -ms- prefixed property for filter, denoting a vendor specific css property, and its value inside qoutes.
What harm would it do to leave it in?
If the browser doesn't understand the line of CSS it will just ignore it.
Those two lines of CSS are almost identical. I would hazard a guess that Microsoft decided to change the syntax for proprietary CSS from IE8 onwards utilising the - (hyphen) prefix which other browsers have been using for yonks.
Technically the CSS isn't W3C compliant either way, so another line of proprietary CSS can do no harm.
It's not worth trying to understand IE at the best of times!
I am new to web design and I have some problems in my website.
First, it is not a cross-browser compatible website. I want to make it so, but I don't know how to do this. I have read some articles about this, but they have not been any help. Please tell me how I can design a cross-browser website.
Second, I have validated my website's CSS file and gotten these errors:
218 .box Property border-radius doesn't exist in CSS level 2.1 but exists in : 6px 6px
219 .box Property -moz-border-radius doesn't exist : 6px 6px
220 .box Property -webkit-border-radius doesn't exist : 6px 6px.
But I don't know how to solve this either.
http://www.harvestcreativemedia.com
border-radius is a CSS3 property, so if you're validating as CSS2, it will report errors.
-moz-border-radius and -webkit-border-radius are "vendor prefixed" versions of the same property. Vendor prefixes are given by the browser makers to features which they have implemented, but which either are not yet standardised or else their implementation of it is not yet complete. Either way, it allows a site designer to use the feature before it is officially ready.
If you're designing a cross-browser site, you need to consider which browsers to include. For example, do you want to take time making it work in very old versions of browsers (which perhaps no-one is using any more)? You need to decide which older versions to support.
This is relevant to border-radius because current versions of Firefox, Chrome and Safari all support border-radius without the vendor prefix. In fact, the vendor prefix hasn't been required for several versions, particularly for the Webkit browsers. So you may be perfectly justified in dropping those prefixed declarations. You need to check which versions of which browsers require them, and decide whether you want to support those browsers.
Another factor to consider is that until very recently, IE did not support border-radius at all, not even with a vendor prefix. IE9 does support it, but most IE users are still running IE8.
If you want border-radius to work for IE, you will need to do some hacks. The best option at the moment for this is CSS3Pie. Your other option is just to ignore it and leave IE users with square corners. Since this won't affect the usability of your site, you may decide this is the easiest option.
All the browsers and browser versions have their own combination of features which they support. A site like CanIUse.com is invaluable for helping you determine whether or not to use any given feature: it shows which browsers and versions support it, allowing you make an informed decision about whether to use it or not.
Finally, the most important piece of advice I can give you for making a site cross-browser: Test it in all browsers, and all browser versions that you want to support. (don't just assume that if it works in one version of a browser it'll work in other versions - you need to test them all).
To fix a website website cross browser the best way is to start it with this in mind and step by step in development to check each browser for any difference and try to find a cross browser solution. You can achieve it with a finished website also but of course it is much more difficult. If you have specific question you can use stackoverflow.com for help in any programming issue you have.
About the errors you get is because you try to validate a css 3 file with css 2.1 standards. Go at http://jigsaw.w3.org/css-validator/#validate_by_uri+with_options and select at profile level 3 css to validate for css 3.
A good thing to look into is jquery rounded corners. it's rather simple and does almost everything that css3 border-radius does. The downside is creating a border,if you want a 1px border you would have to wrap your target div in another div and set the outer to a padding of 1 px.
here is the site: http://plugins.jquery.com/project/corners
download the zip package to view the demo.
This works on all browsers and IE6+, it also adapts correct css properties if they exist for that browser.
I have been learning about IE's rather ridiculous-looking requirements for shadows, gradients, etc., and I'm running into some contradictions on this point:
Many sites suggest the following lines are necessary for a gradient/shadow combination:
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#FFFFFF', EndColorStr='#F8F8F8') progid:DXImageTransform.Microsoft.Shadow(Strength=2, Direction=170, Color='#C6C6C6');
-ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorStr='#FFFFFF', EndColorStr='#F8F8F8') progid:DXImageTransform.Microsoft.Shadow(Strength=2, Direction=170, Color='#C6C6C6')"; }
CSS3Please.com suggests only the first filter is necessary for full compliance with IE 5.5-9, i.e. that the -ms-filter is of no use at all. Is -ms-filter needed any more or was that a temporary case in IE's development?
To answer your question even though I don't agree with its use, no it is not required. The "-ms-" prefix and other prefixes (such as "-moz-" and "-webkit-") are browser-specific and are usually just used while browsers are developing new properties. They leave the prefixed properties in later versions of the browser so that webpages using the prefixed property will still work, but both ways do the exact same thing.
P.S. IE 9 does support CSS3. It was released with Windows 7 SP1.