Conditional Love
14 Comments
Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.
Got something to add? You can leave a comment below.
John Faulds
Ethan
Kilian, good catch—that could easily be a IE7-only condition. I think it comes down to a matter of style (no pun intended). You could easily restrict the conditional just to IE7—of course, doing so assumes that all of the layout bugs we’ve encountered with IE7 are fixed in the next version. Granted, I’ll likely need to edit my conditional in either event, but in the meantime, call me optimistic.
John, that’s interesting. Of course, you should stick with the model that works best for you. From here, I’ve found that clients tend to prefer this method of working with stylesheets, as a.) it doesn’t require them to learn a tangle of rather ugly-looking CSS hacks, and b.) the one-file-per-browser model makes sense to them. And I suppose this approach feels more future-proof to me: I don’t need to worry about IE8 choking on, say, the <code>* html</code> hack when it’s released.
Jon, thanks for weighing in. Just keep in mind that <code>document.write</code> won’t work when XHTML’s served with an XML-ish MIME type.
If you’re using jQuery in your pages, you can use the “.browser” method of the jQuery object:
if ($.browser.safari) { /* … */ }
if ($.browser.opera) { /* … */ }
That’s it!
Kilian Valkhof
Interesting how you use conditional comments for ie7 and above. I always very consciously code for ie6 and below, and ie7 on it’s own. I think you’d be running into problems later on by giving a, perhaps standards based IE8 or IE9, faulty CSS.
Other than that, great article! More people should use conditional comments.
Randy
I like the idea of cleanly putting all your CSS hacks in separate files and using Javascript to load them up. I agree that it sucks to do browser sniffing, but these days you have to because even testing if a browser supports a method doesn’t cut it, because it might support it incorrectly!
I found this site to be a real eye opener;
http://webbugtrack.blogspot.com/search/label/DOM%20Methods
For almost every method available in the DOM, there is at least one browser that doesn’t support it correctly, and 90% of the time that browser has a blue e icon.
I’m thinking of applying your logic to load up custom libraries for each browser rather than have to test everytime I execute a function, if browser a, do this, else if browser b do that.
Something like:
baselib.js
//conditional loads, based on browser detection
ie.js
opera.js
safari.js
(but I might split out the ie.js because between IE6 and IE7 there are a tonne of differences too)
thanks
randy
Jon Rowe
Good article, I’ve been using the same method but with the quick & dirty bit of js below for the last year or so and find it much quicker to code and maintain this way compared to using myriad css hacks
if (navigator.vendor != null) {
if (navigator.vendor.match(/\bApple\b/)) {
document.write(’<link rel=“stylesheet” type=“text/css” media=“all” href=“styleSafari.css” />’);}}
if (window.opera && window.getSelection) {
document.write(’<link rel=“stylesheet” type=“text/css” media=“all” href=“styleOpera.css” />’);}
Wilson Miner
I’ve taken to doing two IE stylesheets lately, one for IE7 and under and one for IE6. I found myself duplicating a lot of fixes that IE6 and 7 both needed, and relatively fewer that IE7 needed and IE6 didn’t.
Ed Eliot
An interesting read but I’m afraid I do have a fairly big issue with plugging CSS holes with JavaScript (as you mentioned some would). Just as one shouldn’t assume JavaScript will be available for core functionality (think progressive enhancement) one shouldn’t rely on support to fix CSS rendering issues.
Whilst I’d always encourage people to avoid server side detection wherever possible I think in these rare situations it’s the best bet. Much of the bad press it received was down to incorrect user agent matching. Whilst Opera, for example, used to identify itself as IE it has also always included the string “Opera” meaning it’s actually not difficult to detect accurately. Browsers could of course completely fake their user agent string and in those situations they might receive incorrect CSS but I’d prefer that than the 4% (potentially) who don’t have JavaScript enabled/available.
Jake Archibald
I think it’s best to have a conditional comment block that targets IE7 and above (as you have in your example). Chris Wilson has said that the next version of IE will operate the same as IE7 unless the developer opts in to the improved rendering engine.
I’m not sure about your isSaf function, it’s not reliable to use object detection for these because none of the objects you’re testing say “this is safari”, you’re relying on Safari being the only browser which supports them, which may not be the case in the future. If you’re going to have browser detections, use something completely browser specific like the user agent string, or browser specific objects like window.opera.
Having said that, window.opera may not be safe to use, look what happened with window.navigator.
Also, browser detection shouldn’t be computed every time, just set it as a variable, or have the function overwrite itself.
Tom Armitage
If you’re working in Ruby on Rails, and implementing conditional comments in your code, then you might be interested in the IE Specific Rails plugin I wrote. It basically generates appropriate conditional comments, including ie-specific javascript or css, based upon filenames of CSS files. It means you just have to put one include in the top of your template, and then just name your IE-specific css/js files appropriately to have them automatically included. It’s not too hard to write such code for the templating language of your choice, really, and it forms a nice framework to build upon.
Arthur van Zuylen
Ever thought about nesting conditional comments?
See this test page for an example. Don’t know for sure if it will speed up page loading…
John Lascurettes
The main two advantages of separate stylesheets referenced by CC for IE:
1. It makes it easier to chuck the rules when you’re ready to retire support for a particular IE
2. It’s a place to stick those proprietary IE rules (like filter: alpha(opacity=80);) that will keep CSS from validating.
That said, I find it easier to keep all my hacks, er patches, in one CSS file. I think I treat them different than the average joe. I use the * html hacks for win IE lt 7 and *+html hacks for IE 7 (this would reduce your first IE CSS patch example in the article by the same amount as a separate stylesheet). Most importantly, these days I tend to group them in one spot in the stylesheet. All * html hacks coming at the end of my stylesheet for example. This way, they’re in the same consistent spot if I need to root them out.
It’s no less cumbersome than having to edit them in a separate file, but I’ve reduced the number of http request.
Eric
C’mon. I bet more people are using ie5 than having js turned of. Dont missunderstand, of course i prefer unobstrusive scripting but lets face it, its going to be more or less deprecated soon, 4% is nothing.
Josh Bryant
Wilson, thanks for keying in… that’s genius! I too have noticed that almost all of my IE7 styles are needed for IE6 as well, which causes a lot of duplication in both 6&7 stylesheets. That makes so much!
When using IE conditional comments, I tend to just use one that targets all versions of IE and then use whatever version-specific hacks (or patches) within that file (e.g. * html) that are needed. I think it’s better to keep all your hacks in the one place and as the length of IE-only stylesheets usually means you can see all the rules on the page without scrolling it’s not too hard to track down whichever one you’re looking for.