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.
Related
I am aiming to support just IE10+, and the newest versions of the most popular browsers. I am wondering if there is a css reset just for those specific browsers ignoring old IE and Moz fixes.
I couldn't find any, but perhaps I have overlooked some when I was searching on Google. I plan to create my own of course, I just don't want to redo work if there is a library out there I can utilize.
Thanks!
Modern as in HTML5 resets?
Blue Print Framework has a nice reset
http://html5reset.org/
Then there is YUI, http://code.google.com/p/reset5/...
A CSS base and reset is meant to apply to all HTML elements you use, so that the browser never has to reach into its default styles to render anything on your page. A few elements have been removed* in HTML5, so you could remove these from your reset if any are present, but that might be over-optimizing. For what it's worth, the YUI 3 CSS base and reset account well for modern browsers.
EDIT:
Correction: They have been marked obsolete; compliant browsers such as IE10 still need to support them, so unless you are sure your page/application will never use any of them, they should not be removed from your base/reset.
Normalize is worth a look as an alternative to a CSS reset. Instead of resetting all styles, it targets the ones that need to change to change to give you sane, consistent results across browsers in a smaller file size.
This means that there is not so many styles to clutter your dev tools debugging. It also fixes some common bugs. It's a mainstream project, that's well maintained, focuses on modern (ie8+) browsers and is used by some high profile sites.
Read more about it here.
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!
Do we still need to use the browser prefixes for css3 properties, for example -moz-box-shadow, -moz-transition: all 0.3s ease-out; etc?
An important thing to take into consideration is that if you are using Vendor Prefixes, then you are clearly using an experimental feature - not only will this property not work in older versions of the browsers you're targeting, and should thus not be used for anything essential, but they are also subject to change. You really shouldn't use experimental features in a production environment.
To answer your question, if you want to target a browser that only supports a vendor-prefixed version of the CSS property, then yes, you do need to do that. However, if you include a non-vendor-prefixed version of it as well, then all browsers will support that declaration eventually.
Found the entry on someone's blog here on SO and I think it's useful. You can use Javascript to make it compatible for all browsers without writing CSS properties for every single browser
For now, yes. Some properties are not supported by all browsers or in different ways since not all properties are set in the standard.
Css3 info
Yes (at this moment). Since modern browsers do not support the same set of CSS3 effects yet, prefixes are still needed.
If you only want to support the latest browsers, then no. Many companies are still using older versions of Firefox or IE, however. So by dropping the extensions you won't have those features, even if the browser supports them.
One important thing is to make sure you use the 'proper' CSS3 rule after the other rules, in this way the browser will use this rule if and when it becomes available. e.g.:
webkit-border-radius: 6px;
-moz-border-radius:6px;
border-radius:6px;
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.
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.