It seems that every time a new version of MSIE comes out, it understands CSS instructions in a different. While granted, MSIE is getting better at understanding the official dialect of CSS it can be frustrating keeping a webpage working correctly on different versions of IE. Fortunately there is a very easy to implement solution to this problem. First as has been preached so many times, one should develop and validate their sites to W3C (http://www.w3.org) HTML and CSS specifications. and use a "standards compliant" browser like Firefox or Opera as the primary testing browser. Next one can address individual display issues for each version of IE using the following code and creating individual CSS files for each version of IE that ONLY contain the tweaks and fixes need to get a page to render correctly in the corresponding version of IE. <!-- Internet Explorer specific CSS fixes //--> <!--[if IE 5]> <link href="/css/ie5.css" rel="stylesheet" type="text/css"> <![endif]--> <!--[if IE 6]> <link href="/css/ie6.css" rel="stylesheet" type="text/css"> <![endif]--> <!--[if IE 7]> <link href="/css/ie7.css" rel="stylesheet" type="text/css"> <![endif]--> Code (markup): Because the instructions above are wrapped in comments they will validate to W3C specifications and only the specified version of MSIE will see any individual instruction. This makes these MSIE only fixes fail safe in that browser user agent spoofing will have no effect on the effectiveness of these tweaks (unlike server side browser detection tricks) and they work regardless of whether or not the browser has JavaScript enabled (unlike JavaScript browser sniffing routines). It isn't often that Microsoft makes our life easy, but the [if IE] trick can create very elegant solutions to browser compatibility issues. Personally my [if IE] stylesheets normally contain only a few instructions for any given version of IE and in fact I didn't need anything at all for IE7 on my environmental chemistry site. Just remember code to W3C specifications and do all development testing on either Firefox or Opera. Then go back and use the tactic above to address individual rendering issues in each individual version of MSIE.
Prefer to use filters instead; Targeting IE5 * html #selector{width:500px} IE6 * html #selector{w\idth:500px} Giving different widths to IE5(500) and 6(480) * html #selector{width:500px; w\idth:480px} IE7 http://www.ceprix.net/archives/css-filter-for-ie7/
These can cause problems for other browsers and cause CSS validation errors. This is an unreliable method at best that takes advantage of browser flaws. It is always better to used designed in solutions like the [if IE] method than to try and exploit flaws in a browser. If nothing else, the [if IE] method is easier to manage.
Those don't cause parse errors, I wouldn't have recommended them. IE 7 *:first-child+html {} to select the html element. The IE7 filters are tentative at the moment due to lack of testing. So it's not a 'catch all'. "Unreliable at best?" The IE5&6 ones work perfectly.
I didn't say "parse errors" I said validation errors and I mean when a page's CSS is validated against W3C's CSS validator. Regardless, those suggestions are still relying on flaws in the way different browsers handle poorly formed CSS. This is a flawed way of addressing these types of issues. MSFT specifically implemented the [if IE] "trick" to allow developers to address issues specific to each version of IE without having ANY risk of causing problems with other browsers. You can not guarantee that the next version of browser 'X' will not trip up using the CSS hacks you presented, but I can be assured that NO browser other than IE5 will read and act on my [if IE5] instruction and only IE7 will act upon my [if IE7] instruction. Another advantage to the [if IE] method and version specific stylesheets is that it allows one very clearly isolate out what work a rounds are used for which version of IE. This can make resolving issues very quick and easy as one doesn't have kludgey browser specific "hacks" polluting the main CSS file.
They don't cause validation errors. That, too, would be unacceptable. If the next version of browser x would start parsing invalid css, then it'd be a pretty damn stupid browser. As a browser develops it will take steps forwards, not backwards and the filters will gently disappear over the years. There's no need currently to add extra mark-up to the page. I'd rather have the bytes cached in a CSS file on larger sites. You can create perfect pages without it with the correct filters. So far, no new browsers trigger old bugs. There are numerous advantages conditional comments method, especially if you're having trouble with browser support - filters and browser bugs are hard to learn to overcome. I respect your choice, but my opinion is different to yours and until there's a valid reason to change, I won't be baby feeding Internet explorer with individual stylesheets and additional mark-up.
If your method works without throwing validation errors or warnings via W3C's CSS validator, it sounds like a viable alternative. There are after all many ways to skin a cat. This is one thing I really like about the [if IE] method, I can keep each set of IE fixes nicely grouped together such that they can be easily dumped by removing one line of code when the time comes. In addition that code doesn't clutter up the primary CSS files with browser specific stuff. To each his own, but your solution still adds extra markup, just to the CSS file instead of the Page header. My method only adds 87 characters to the the HTML file per browser version. This is hardly cluttering things up and one would need way more clutter to a CSS file to document browser specific fixes. In addition the IE only CSS files would ONLY be downloaded by their respective versions of IE. Indeed, while I keep the trick I posted above in my toolbox there are very few instances where I really have to deploy it, but when I do it is nice to have. Here is the one really big advantage of my method. One doesn't need to remember a whole series of arcane CSS hacks. One simply creates a separate CSS file for each IE version they are having problems in and throw in one or two CSS instructions that address the issue at hand. This is much easier to remember. and implement. But you are baby feeding IE with version specific instructions only thing is you are also cluttering up your primary stylesheet in the process. BESIDES YOU MISSED THE POINT OF MY THREAD. My purpose wasn't to say mine was the only solution, I simply provided an easy to remember solution that could save a lot of people headaches if they want to use a different solution that is their propagative. I am only providing people with a little free help. We don't need to get in a pissing match about what version is better. They both have advantages and they both have disadvantages.
The baby-feeding was a metaphor for feeding IE versions individually, instead of each browser reading over a css file and discarding incorrect css. I never missed the point, post 2 was my suggestion for a 'better method'. As always it then elevates from there due to differences of opinion. If you go to our site: http://codepress.co.uk and check the stylesheet, you'll see what I've done to separate the filters from the main documents. Because I agree, it's necessary to ensure you 'tag your filters'. All in all, I'm off to bed. Thanks for the debate, it's always important to see it from someone else's point of view.
The result is the same, special code is provided to deal with specific browser issues. Yes it is a matter of opinion, but the reason I do not like your method and think it is kludgey is that it requires one to either remember why they put some specific rule in their stylesheet or to document the line of code explicitly. This means that the stylesheet will become loaded with obsolete detritus over time. By calling specific stylesheets for each version of IE using [if IE] to deal with specific issues one is isolating out specific browser fixes from the core code set and one doesn't need to explicitly document why something was done. Also one can easily purge all fixes for a specific version of IE (e.g. IE5) by simply purging one line of code. Personally speaking I have a hard enough time cleaning out unnecessary CSS instructions that have become obsolete due to design evolution. Let alone trying to clean out code for obsolete browsers. Finally one doesn't need to remember how to make IE5 do something vs IE6. Instead one simply has a different almost empty CSS file for each version of IE (e.g. IE5.css, IE6.css & IE7.css) and one can quickly drop the appropriate fix in the appropriate file. Documentation is simple, tracking and organizing IE fixes is straight forward and automatic and one doesn't have to remember a mess of different and obscure browser specific CSS commands. Personally I don't want to remember what CSS trick effects IE5 but not IE6 or Firefox. Your method may be more "pure" in that it doesn't require separate CSS files, but it is also more confusing in that it requires having a reference sheet of esoteric CSS hacks and careful documentation. All one needs to remember by the method I mentioned above is "<!-- [if IEx]> <![endif]-->" where 'x' is the version of IE being targeted. There is no need to remember esoteric instructions. If one wants to target all IE browsers, the version number can be left off simply using "[if IE]." One can literally put any HTML code inside of the [if IE] instruction they want. In fact, this would be an excellent way to target "Spread Firefox" ads to IE users.
Well, I'm a noob with css, I understand the concept, and am learning it slowly but surely on an "intuitive" & experimental level as opposed to actually understanding the language (I was never any good at foreign languages - might sound mad but it's working for me) ... but KLB's strategy certainly sounds like a much more logical (and therefore "better" imho) approach to me. Cheers KLB css is hard enough to learn and absorb, without having to remember why you put some random ie hack into your css file in the first place. Sorting it out in this way will not only be easier to "clean-up" at a later date, but also speed up my own learning curve, simply because the good css and the bad (hacks) css, are seperate entities... if you know what I mean