The cursor spec is pretty old. Am I missing something in terms of cursors that I should be accounting for in my CSS other than just prefixing the cursor value?
Edit: I'm referring specifically to the "grab" property and others like it, which require "-webkit-grab". Sorry for the confusion.
The grab value is new to css-ui-3. This was during a time when anything that was new and experimental came in the form of vendor prefixes, including values. I'm not sure why Chrome hasn't still unprefixed it yet considering Firefox 27, released two and a half years ago, now supports this value unprefixed. Microsoft Edge also supports it unprefixed, though Internet Explorer does not.
It doesn't, you can use cursor just fine in Chrome.
Fully supported in all browsers - http://www.w3schools.com/cssref/pr_class_cursor.asp
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'm developing a website for a customer, and I've tested it with the major browsers on Windows.
Now I'm facing some little differences between Chrome Win and Chrome Mac (same version).
These are really minor things, but the customer spotted them, so I'm wonder.. there is some reset I can do via css to make the two version as similar as possible?
I think I've to work with the -webkit prefix of the browser default, do you know any good walkthrough?
I mean: there is some base .css I could use to reset Chrome and to force it to render as similar as possible even cross-platform?
Thanks!
UPDATE: the differences I mention involves mainly font-sizes letterspacing and something related with the height and line-height of the elements.
What you're running into is default browser css definitions. It's always a good idea to reset or normalize your CSS when starting a project so all browsers behave the same way with the base elements.
http://meyerweb.com/eric/tools/css/reset/ << reset. Sets all common CSS to 0. This one can be difficult to use since it means styling EVERY element you want to use. ie lists no longer have any default padding or list style.
http://necolas.github.com/normalize.css/ << Normalize gives you some default settings, but still tries to bring all modern browsers to the same starting point.
When it comes to prefixes really only some of the CSS attributes use them. There is a good explanation here: http://webdesign.about.com/od/css/a/css-vendor-prefixes.htm
List of which browsers use which prefix:
Android: -webkit-
Chrome: -webkit-
Firefox: -moz-
Internet Explorer: -ms-
iOS: -webkit-
Opera: -o-
Safari: -webkit-
Also keep in mind some CSS properties need to be defined differently for older versions of IE using filters. Opacity is one of those.
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 know IE8 and below don't support rounded buttons with plain css but does ie9?
I had a more recent table showing CSS3 properties handled by IE9 but border-radius was already part of them in september: http://www.impressivewebs.com/css3-support-ie9/
Microsoft's stated aim in releasing IE9 is to support all HTML5, CSS3 and other features which for which finalised specifications have been released.
This means that there are a number of features which Firefox, Chrome, Safari and others support already which IE9 will not support.
The good news for you is that border-radius (the CSS3 feature which gives you rounded corners) is fully specified, and as a result, it is implemented in IE9.
I recommend using the site CanIUse.com to check for browser support for individual features. It has a comprehensive list of which browsers support which features.
You may also want to look up Quirksmode.org, which offers a similar service. However although I am a big fan of Quirksmode, it is getting somewhat out of date now. (but it is still a great resource for checking feature support in older versions of IE in particular)
As of right now I believe only Firefox support -moz-border-radius property. I am surprised that twitter uses it.
Are any other browsers planning on supporting this or does CSS3 have something like this in the works?
Edit: I also found -webkit-border-top-left-radius and then the CSS3 version
So when is CSS3 coming out?
CSS3 has border-radius.
For now, Mozilla- and WebKit-based browsers have experimental support, -moz-border-radius and -webkit-border-radius. It's not bad to use them now, as long as you understand they are temporary measures until they are properly implemented. I would expect it's not too long before you see full support for border-radius in Mozilla, Firefox and IE. (Well, hopefully IE.)
Update: as of August 2016, with border-radius being natively available in all native desktop browsers (and most mobile browsers, not to mention), the stringency of using -moz-border-radius, -webkit-border-radius and similar is being slowly relaxed.
Because the CSS3 spec hasn't been finalised, Mozilla and Webkit decided to implement their own method of rounded corners, doing it in the correct way, by adding the vendor-specific tag at the front.
This is done so that when the CSS3 is FINALLY released, should they change how border-radius is supposed to work (eg: the order of the parameters), then none of the sites using the vendor-specific methods will be broken. Mozilla and WebKit can just go ahead and implement the W3C style and developers can slowly move over to that.
It's not too surprising that you're seeing some websites using it, especially for something like rounded corners where it's not going to make a massive difference to the user experience. And I mean, it's just IE users who are missing out, and they deserve everything they get.
It bugs me when people talk about CSS3 coming out. It's not a complete spec like the previous ones. It has been broken up into separate modules that may increment their versions independently.
So Selectors Level 4 may make Recommendation before CSS Backgrounds and Borders Level 3 does.
So, will CSS3 arrive? Eventually, but not all a once. So don't wait for it, start using it now (where applicable).
CSS3 has something like this in the works.
According to this, IE 8 will not support border-radius.
Any CSS property that starts with a dash (e.g. -moz, -webkit) is a browser-specific property.
This allows browser vendors to experiment with new CSS properties. Doing so is a common part of the process for writing new CSS specs, to allow web developers to see how the properties work and raise issues.
Hence you’ll find a lot of CSS 3 properties, like border-radius currently implemented in some browsers with vendor-specific extensions.
There’s nothing particularly wrong with using these on production sites, as long as you’re aware they’ll only work in the one browser.
CSS 3 should be out any decade now :)
Browser-based properties are only meant for interim fixes for that particular browser, and are supposed to be deprecated when either the W3C adopts them into CSS, or not. I wouldn't rely on them to be cross-browser or even be kept for the particular browser.