This question already has answers here:
Do we have to use non-standard/browser specific CSS vendor prefixes anymore?
(3 answers)
Closed 8 years ago.
I was just wondering to what extent is it still necessary to specify vendor prefixes like 'webkit', 'moz', 'ms' or 'o' in CSS these days.
If I understand correctly, opera switched to webkit, so that drops '-o-', right? IE dropped the need for '-ms-' in IE10, but do you still need it for older versions? And I'm not sure what the story is with '-moz-' right now.
Basically all my CSS3 seems to work just fine across all (up to date) browsers without specifying any prefix, so I was just wondering what is necessary and what isn't necessary as of mid 2014.
EDIT: Basically I'm just wondering does anyone have an up-to-date list of what prefixes are necessary and under what conditions are they necessary.
You can build a filtered list on this web page and show all of the required prefixes.
http://caniuse.com/#comparison
for the most part, you may find things work great in the latest browsers without vendor prefixes. BUT I will point out 3 reasons why you might want to keep using them at least some of the time and then you decide for yourself when you think it is appropriate.
(as was mentioned already) Not everyone is using the most up to date browser.
You won't break anything by using vendor prefixes even in cases when you don't need to, so it can only improve your site and not harm it.
If your using prefixes (etc) from a service like http://www.colorzilla.com/gradient-editor/ then it's a trivial copy-paste and you gain nothing by not using it (except perhaps a smidgen of file space)
Related
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
This question already has answers here:
List of CSS vendor prefixes?
(3 answers)
Closed 7 years ago.
I have a stylesheet that I made 2 or 3 years ago, when CSS was full of these horrible vendor prefixes for flexbox. I used flexboxes as needed, with the -webkit- prefix for Chrome & Safari.
I just saw on caniuse that flexboxes are now working without prefix on every browsers. Do you know an up-to-date list of CSS properties that still need prefixes?
At that time, vendor prefixes were needed for things like gradients or animations. I wonder if I can remove everything safely, or if some of them are still used.
I was looking for the same a while ago, and ran into this useful website: Should I prefix?. It lists the CSS properties and whether a prefix is still necessary or not.
Next to that, you can always check Can I Use for more info and detail.
+1 to caniuse.com as the best place to see browser prefix info. But your flexbox use case is unique.
Flexbox's implementation has changed a lot of the years, far more than almost any other CSS standard I am aware of. The best way to check which version you are using is to check the display value in your stylesheet.
display: box is the oldest implementation, you probably didn't use this one.
display: flexbox was the transitional state between the old and new flexbox standard. If you are 2-3 years out, you might have used this and will have to change your code to match the new implementation.
display: flex is the modern implementation that has good cross browser support. If you used the prefix version of this, you should be able to safely drop prefixes and get the same results.
CSS Tricks has one of the best shorthands for the modern approach to flexbox: https://css-tricks.com/snippets/css/a-guide-to-flexbox/
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!
This question already has answers here:
Detecting IE version using CSS Capability/Feature Detection
(18 answers)
Closed 5 months ago.
So in my interweb travels of evaluating other programmer's CSS I've noticed a bunch of people using the underscore or asterisk hack that is vendor specific to IE browsers for debugging purposes though W3C does not parse this as valid CSS.
I personally prefer comment conditionals where you can at least defer to IE specific CSS that is valid but I guess the only issue with that would be addition of extra CSS.
So I'm curious about a consensus of what you prefer and the positive or negative implications of each method.
Comment conditonals or IE vendor specific hacks?
PS - Honestly this should be titled do you support IE layout or not :-)
Conditional style sheets are the way to go. The word hack itself implies that you're doing something that you shouldn't. But a few short words on both:
Conditional style sheets
(+) Cleaner CSS code
(+) Easier to manage
(+)Easiey to understand for other developers
(+) CSS validates
(-)More CSS files (thus more server load)
Hacks
(+) Faster (possibly)
(-) Messes up your CSS
(-) CSS doesn't validate
(-) Very unclear for other developers (especially non-experienced one's)
(-) Could cause problems with newer versions of IE
I prefer the conditional comments, because it makes your page still validate. I could imagine, however, that you use the vendor hacks, because you won't need an extra css file, saving a request per page loaded (if not for caching, of course). Then again, the css files are cached, and if you use your conditionals wisely, you can make a separate file per IE version, copying hacks if they are needed for more than one version. That way, you need at most one extra css per page, which is then cached as well, thus minimizing the extra load.
I am trying to figure out the most efficient way to ensure cross-browser compatibility. I have done a bit of research and learned a few interesting things such as the fact that Mozilla/Firefox can't handle a class that has a name starting with a number. Is there a way to make a CSS work for any browser or is it better to just develop multiple CSS and add code to choose which to use based on the browser being used?
You might consider using a CSS Framework such as Blueprint. It includes a CSS reset that should help.
Also, you might want to look at Yahoo's CSS reset
An aside to clarify a point:
... I have done a bit of research and learned a few interesting things such as the fact that Mozilla/Firefox can't handle a class that has a name starting with a number....
Sorry, but that's not a Mozilla limitation, it's in the CSS spec: class names must not start with a number. Any browser that allows them to isn't enforcing the rules properly.
Answered here on StackOverFlow. The relevant part of the spec is at http://www.w3.org/TR/CSS21/syndata.html#characters (see the 2nd paragraph).
To answer your question: There is no way to make a page using just one universal css and have it displayed equally in all browsers, unless you only use an extremely small sub-set of all available css (selectors, values, etc.).
The way I work is:
Use a css reset
Develop for a browser that adheres to the standards pretty well (Firefox, Chrome, Safari, Opera)
Patch things up for IE using conditional comments (because you'll probably need things that don't validate)
A good starting point would be to use CSS reset such as: http://developer.yahoo.com/yui/reset/
Your goal should be CSS that works on all browsers. If you start out with a CSS file per browser, where do you stop? Mobile Safari? Flock? Konqueror? Every version of every supported browser?
Eventually, you might need to compromise, but you can cross that road when you get there.
Regardless of your infrastructure/framework/etc you should test your code on all major browsers. If possible avoid using style sheets for browser specific problems. Browsers will change and adapt which means you might get stuck having to update a bunch of websites when new browsers come out.
CSS is a fickle beast and I haven't found any solution that covers all the quirks except for a lot of due-diligence and testing.
You might use a framework that does this for you, such as GWT, but keep in mind that you will still have some issues.