I recently looked at the following question:
How to disable text selection highlighting using CSS?
Which nicely provided the answer to the immediate CSS problem I was facing. However, it made me wonder, how do you determine when it is safe to drop all the browser specific prefixes for CSS properties?
I know how the mechanics of this work, older browsers which require a prefix will of course always need a prefix, so I suppose the answer really depends on the browser usage statistics.
Is there a decent, simple, source of reference that can be used to determine whether all these prefixes are really required for a CSS property, e.g. if I use the user-select property without prefixes, I can guarantee 95% of browsers will interprit this correctly.
This is an excellent summary of browser support for pretty much every CSS property.
However, I tend to use the browser-specific prefixes, as well as the non-specific rule, no matter what - it's not exactly much extra work and it will mean those few people stuck on outdated browsers still see the page as you intended.
One good resource I've used for this sort of thing is http://caniuse.com/. In general, it is not a bad idea to have a list like, for example,
-webkit-border-radius: 3px;
-moz-border-radius: 3px;
border-radius: 3px;
For the space of a few lines, this ensures that older browsers will get the right browser-specific rules if they require them, and that newer browsers get the standards-compliant rule.
Edit: Well, I noticed that the resource to which I linked does not have an entry on user-select. Oops!
I've found this to be the best resource for that:
http://www.w3schools.com/cssref/css3_browsersupport.asp
Related
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.
Here's an example style supported by most browsers:
.class {
background: rgba(0,0,0,0.3);
}
Old IE (IE 6-8) don't support rgba. There are at least three methods I could potentially use to support this.
Same class
.class {
background: grey;
background: rgba(0,0,0,0.3);
}
Modernizr
.class {
background: rgba(0,0,0,0.3);
}
.no-rgba .class {
background: grey;
}
star hacks
.class {
background: rgba(0,0,0,0.3);
background: grey\9; /*IE8 and below*/
}
I prefer to use methods 1 and 2 because they cover more than just IE browsers, but I'm not sure which method I should use.
Method 1 is good because it works even if JS is disabled. However, there's an extra attribute to render for all modern browsers.
Method 2 is good because it segregates the bad browsers into their own classes. Modern browsers won't render this class which saves milliseconds of rendering time.
Maybe there's something else I'm not thinking of that could be better? I'd like to avoid using PIE.htc or filters. What is the best method for optimization and load time?
For this kind of style, the correct answer is the first one you listed:
.class {
background: grey;
background: rgba(0,0,0,0.3);
}
Specify the fall-back options first, followed by the preferred option.
IE will set the background to grey because it doesn't support rgba; other browsers will use the rgba version as intended.
The reasons this is the best answer are:
It is the canonical "correct" answer for this exact scenario: CSS was designed to work this way, with exactly this kind of situation in mind.
It is the least expensive option, because no browser has to do any extra rendering or scripting. IE will completely ignore the second background, so nothing extra happens there; other browsers will parse both, but parsing the second will overwrite what has been parsed for the first, so the only overhead is the parsing, which would have to be done anyway for whichever option you pick.
Of the other possible solutions, Modernizr is great, but is overkill for this scenario -- if you have a solution that doesn't involve any scripting, there's no need to use a scripted solution. And the CSS hacks should be avoided at all costs. There may be cases where they are worth using, but I personally haven't seen a legitimate use for one since I stopped trying to support IE6.
The other solution that is available but which you didn't mention is conditional comments: ie use IE's <!--[if IE]> syntax to load an alternative stylesheet for IE. However I would avoid this as well if possible, and again, the need for this kind of solution is fading away as IE6 and IE7 become more distant memories.
Finally, a slightly different option for you: Just ignore old IE. For some things, IE8 may not render things the way you want, and it's a pain to make it do so. In these cases, it is a perfectly legitimate strategy to just let it fail. For the example in the question, this isn't necessary, as we have a perfectly good CSS solution, but for other more complex styles, consider how bad the site will look if IE doesn't get things right; if it's still usable, then there may be a case for simply letting it slide. This option needs to be weighed against the number of users that will be affected and how much of a problem it causes for them, and also the requirements you're working to, but it should be considered as an option.
Your method #1 is the generally accepted way, because not only does it handle IE, but it also handles any browser that doesn't support the CSS in question (in this case, RGBA). The rule for CSS that browsers are supposed to follow is that if they don't recognize a line, they ignore it and move on. As for more capable browsers, CSS such as this is cheap, and the browser may not even render the fallback CSS at all (I know most don't download the image for image-based fallbacks).
Method 2 not only adds classes (which add weight), but adds an entire JavaScript library. If you're dealing with a bunch of other CSS3 type stuff (especially things that don't have such easy fallbacks), then it's not a big deal, but if you're using to handle fallbacks such as these, or just one or two, then you're adding a lot of overhead (including potentially another HTTP request) for not a lot of extra benefit. Even if the modern browsers don't render the classes, they do have to run the JavaScript to check for the capability.
Method 3 is a hack and should be avoided whenever possible (I recommend conditional stylesheets over resorting to hacks). Not only does it target only specific versions of a specific browser (thus leaving all the other browsers that don't support this CSS out in the cold), but relies on bugs in a browser to get the job done. And what happens if that code triggers a different bug in a different browser, or if a browser recognizes the line with the hack, but also behaves properly with the correct CSS? Have a look at some of the tutorials circa 2005, when IE6 and IE5 for Mac were still major contenders, and see the crazy lengths people went to with browser hacks to keep them from stepping on each others' toes. (Note: I do not consider prefixed CSS to be hacks. Prefixed CSS items are documented functionality that the browser vendors chose to add and serve the stated purpose of sandboxing those features. If they are for things that make it into the standard, then they are designed to be phased out over time.)
So, in order of preference - Fallback CSS, Modernizr, Conditional Stylesheets, Browser Hacks.
Is it necessary to have valid CSS? I am using Twitter Bootstrap for rapid web development and after running the two main Bootstrap style sheets through the W3C CSS Validator, I noticed about 600 errors.
My question is, my site looks good so why is it so important for the CSS to be valid?
Yes, it is absolutely necessary to have valid CSS. CSS is a programming language and as such, you must follow its language rules. Just because browsers tend to accept invalid HTML and try to render it, it doesn't make generating ill-formatted HTML a good practice. The same is true to CSS, although - fortunately - CSS rules are quite a bit stricter than HTML rules.
Another reason is that valid CSS has guaranteed behavior - if you write a rule, you can expect that rule to behave a certain way. (Buggy browsers, like all versions of IE aside.) If your CSS is invalid, any behavior you get is undefined and it may break when a patch release is issued for any of the browsers that you use for testing. Your CSS won't necessarily break but when you write invalid CSS, you get no guarantees of any behavior - you simply get some behavior that may seem correct to you but that may change any time.
If you have correct CSS mixed in with incorrect CSS, browsers tend to ignore the invalid parts (just how the specification tells them to) but each browser does it slightly differently. Similarly, while many people advise to use CSS hacks, I'd say not to, for the above reasons.
The CSS doesn't have to be valid to work. Browsers simply ignore the CSS that they don't understand.
Validating the CSS is a method to test if it follows the specification. If it does, any browser that is up to date with the specification used will understand the CSS.
It's somewhat of a debated topic really. The W3C tools are certainly good to use, but they tend to not account for a lot of modern code. Naturally, it's difficult for them to not only advance standards, but also make sure the tools they offer are accountable to new and inventive code.
In order to get websites to look good in all browser and across all platforms requires people to maybe stretch outside of the norms that otherwise would be "valid". It's tough to argue against a site that works perfect cross browser and platform even if the CSS isn't 100% spotless. That's my two cents.
Your CSS doesn't need to be valid (depending on who you ask), but if it is invalid, you should have a reason for the invalidity:
audio,
canvas,
video {
display: inline-block;
*display: inline;
*zoom: 1;
}
The validator has a parse error here because of the asterisk at the beginning of property. This is a obscure but recognized hack for targeting Internet Explorer. Other browsers will ignore the properties that it won't recognize but IE6/7 will read properties with asterisks.
input:-moz-placeholder,
textarea:-moz-placeholder {
color: #999999;
}
input:-ms-input-placeholder,
textarea:-ms-input-placeholder {
color: #999999;
}
input::-webkit-input-placeholder,
textarea::-webkit-input-placeholder {
color: #999999;
}
The validator error here is a result of vendor-specific pseudo-classes. Note than unlike unrecognized properties, if a browser doesn't recognize the selector the entire rule will be ignored so the vendor placeholder extensions need to be separate rules. This happens even when using the comma operator so:
input::-moz-placeholder,
input::-ms-input-placeholder,
input::-webkit-input-placeholder, {
color: #999999;
}
would be ignored in all browsers unless they recognized all three vendor prefixes.
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#fffbb450', endColorstr='#fff89406', GradientType=0);
This is the old-style IE extension for gradients. It ripples and causes a number of errors in the validator even though IE follows it and other browsers will not quietly ignore it.
width: auto\9;
The \9 is another IE hack that targets IE<=8
The bottom line is that if you are doing something non-standard, make sure you know why you are doing it.
Now a days there are different number of browsers with different number of versions.Some supports lot but some are not.So when you include styles it is always not possible to fit 100 % perfect.If your style works without any problem ok.But when it goes to different browsers if you get problem related CSS , You have to take care otherwise no problem.
yes its important, most of browsers follows the w3c standard when they load the html page. if your page don't have the valid css, in different browser it might appear different ways. Old internet explorers didn't followed the W3c standards which cost alot to the developers result in developer need always extra css for the IE to display page properly.
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.
today I hit F12 in FF to load FireBug to see what my site was thinking. Then saw this:
The facts showing from above:
My site likes using them "rounded", alot of them...;
My site is loaded with errors, at least as FireBug sees it.
Is FireFox right and should I assess this and if so how do I change it since I think this is crucial for IE and is the default CSS3 spec, right? Or is there something else happening thats causing all this things to show up in FireBug? I would be happy to hear what I should do to make all this disappear again, really.
Open the drop down in your console tab and un-tick stuff like "show CSS errors".
Also, it's not a bad thing. If Firefox comes across a property it doesn't know (such as border-radius at the time this question was asked) it will just ignore it and continue with the next property. This is why for instance -webkit-border-radius: 2px; -moz-border-radius: 2px; border-radius: 2px; works. Firefox will ignore the -webkit- prefixed one, it would recognize the -moz- prefixed one and ignore the non-prefixed one because the non-prefixed one had not yet been implemented in the version of Firefox you used. (It is now no longer needed to prefix border-radius unless you're supporting an ancient browser)
You might want to pop the IE-specific properties (filter and zoom) into an IE-specific stylesheet, and include that with conditional comments.
As for the rest, you’ve just got an older version of Firefox that doesn’t recognise the newer properties. That’s fine, it won’t do any harm. (Somewhat odd that moz-opacity isn’t recognised, as I thought that had been around for ages, but it’s fine.)
Check this
I think you need to use -moz-border-radius:... declarations for FireFox :)