This tutorial shows a css blur example with
img {
+filter: blur(30px);
}
then goes on to mention "Note: + stands for vendor prefix". Why is a plus sign used here instead of a vendor prefix such as "-webkit-"?
It's shorthand copied from this authoritative tutorial site. On HTML5Rocks however they didn't neglect putting the correct hover on there, stating "Please apply relevant vendor prefix".
As such, +filter should indeed correctly be written as:
filter:blur(30px);
-o-filter:blur(30px); /* rather obsolete since Opera switched to Webkit */
-ms-filter:blur(30px);
-moz-filter:blur(30px);
-webkit-filter:blur(30px);
The origin is the Compass extension to SASS which allows this syntax as a real shorthand for vendor specific rules.
As you can see on this site however only Webkit currently supports filters. As such you can also ignore the -o- prefix for features that won't be added to Presto anymore anyway.
Related
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.
I am running through CSS3 tutorials and I have come across these new requirements. Obviously each browser has different implementations, so you must tell your style sheets to use them. How do you know when a certain browser requires a certain prefix? Is there a single resource that tells you? Is there some sort of magical ultimate include in CSS that will take take of it for you?
On http://caniuse.com it's reported if a CSS property needs the prefix.
Example: http://caniuse.com/#feat=border-radius you can see that old versions of Safari and Android need the -webkit- prefix.
Remember also to place the prefixed properties before the unprefixed one.
This question already has answers here:
Why do browsers create vendor prefixes for CSS properties?
(2 answers)
Closed 3 years ago.
I just downloaded a css file from this website and it contains properties such as -webkit-transform and -moz-transform. What does the dash mean and under what circumstances is it required?
For the nity grity does the phrase "vendor prefix" refer to the - or the content between the - and - (exuding the - and -) or the content between the - and - (including the - themselves)?
In other words does vender prefix refer to the dash itself or only the content between the dashes or the dashes with the content between them?
-webkit- and -moz- here are called vendor prefixes; they generally indicate a browser-specific feature of CSS, or one that’s under development/still a draft and can’t be considered a standard yet. When these features are used “ahead of time”, the only way to make it work in every browser is sometimes to provide a different rule with a different prefix for each one — that’s what you see in the project. The idea is that eventually, though, the feature will be standardized, browsers will drop the prefixes, and life will go on.
-webkit-gradient, for example, was the first way to define a gradient in CSS, but was replaced by a completely different linear-gradient and radial-gradient syntax.
A convenient way to find out what browsers support a certain feature and what prefixes you need if you’re using it before a definitive standard or global unprefixed browser support is Can I Use….
Some common prefixes are:
-webkit- for WebKit-based browsers, including Chrome/Chromium and Safari
-moz- for Firefox
-ms- for Internet Explorer (9 and up)
-o- for Opera (pre-WebKit)
They are called vendor prefixes. Different browsers have different prefixes:
-webkit- - Webkit based browsers such as Safari and Chrome
-moz- - Gecko based browsers such as Firefox
-ms- Internet Explorer
-o- Presto based browsers such as Opera
Vendor prefixes are used to denote experimental CSS features. They are used when a specific property or spec is not considered stable, and may change in the future. By using a prefix, the browser can experiment with that feature without the risk that developers will make use of the property and sites will break if the behaviour or syntax changes. Once the spec becomes final, the prefix is removed, and some browser will remove support for the prefixed version.
The official guidance from the W3C is that prefixes should be used until the spec from which the property or feature is from reaches Candidate Recommendation.
The general best practice is to use all vendor prefixes one after another, and the unprifixed version last.
Mozilla and Chrome (now they're moving to the Blink engine) have changed policy to hiding the feature behind a flag, rather than using a prefix. This means the feature will not be available to use unless the user enables that flag.
For more information, see this wiki page from the CSS Working Group: http://wiki.csswg.org/spec/vendor-prefixes
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've seen CSS styling along the following lines:
input::-webkit-input-placeholder {...}
or
input:-moz-placeholder {...}
And they raise a few questions for me:
What are these things called? (I'm having trouble googling them.)
Is there a comprehensive list somewhere of which ones are supported by which browsers?
Which meta-CSS languages (Sass, Less, Stylus, etc) have support for these, if any?
Thanks!
The thing with one colon called pseudo-classes, it is used address different states of object (like :hover and ‘active).
Shot description and list can be found there: http://reference.sitepoint.com/css/css3psuedoclasses
Description on w3.org: http://www.w3.org/TR/selectors/#pseudo-classes
The thing with 2 colons called pseudo-elements, it is used to autogenerate content or to style part of content like first letter of first line.
Description on w3.org: http://www.w3.org/TR/selectors/#pseudo-elements
There is lot of browser-specific extensions of this list through. That didn't documented in css3 standard.
You can find list for Mozilla's browsers here: https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions in the section "Pseudo-elements and pseudo-classes".
Can't find good list of Webkit pseudo-elements and -classes through.
They're called vendor specific properties, and they typically are a vendors version of a CSS3 format. Since CSS3 isn't a standard yet, technically any browser that implements them are implementing a vendor specific extension.
-moz mean Mozilla, aka firefox, etc..
-webkit means webkit based browsers, ie Safari, Chrome, Konqueror, etc..
-ms
See: http://reference.sitepoint.com/css/vendorspecific