Why bother supporting more than one browser? For anyone wanting to hit a large proportion of the population then supporting Firefox 2, Firefox 3, Internet Explorer 6 and Internet Explorer 7 are necessary to satisfy 89% of the market (browser stats). It may also be desirable to support Chrome and Safari to get to 96%.
That is a lot of platforms – all with their own behaviours and interpretations of specifications. I’ll ignore arguments about upgrading browsers / converging on one/two browsers as that is a big topic that is regularly argued about the world over.
So, here is how I cope with the joy of cross-browser compatibility
Before we can fix something we need to know it is broken. The approach I take is to try out the web site on all the browsers I want the site to work on – unfortunately, it’s not that simple to have all possible browsers on one machine.
Firefox 3 and Internet Explorer 7
These two are easy – I have them installed all the time on my development machine. They co-exist quite peacefully and give me no grief.
Firefox 2 can be completely standalone as a portable app. Stick it in a folder and run it, at the same time as FF3. Here’s how
Internet Explorer 6
Rumour has it that you can install Internet Explorer 6 as a standalone application. I’ve had no luck with this approach. My approach is to use a virtual PC. Microsoft have kindly made Virtual PC 2007 available for free here. They also provide images for the common setups here.
This is available from Apple as a download for the PC, here.
Tweaking for Compatibility
So, we’ve now identified a problem with our site in one of the browsers. Searching the internet will usually reveal the necessary tweak for that browser. There are also countless tricks out there for making our CSS only appear to a particular browser. Such as:
/* Hide from IE-Mac \*/
/* End hide */
I generally don’t like these approaches as they obfuscate our CSS to some extent, this then leads to mistakes. So, what do I prefer?
Browser specific CSS in browser specific files. For any of my sites my stylesheets will generally look like:
- default.css – included by all browsers for the core style
- ie6.css – included only by Internet Explorer 6
- ie7.css – included only by Internet Explorer 7
- ff2.css – included only by Firefox 2
- Firefox 3 is omitted as I develop in Firefox 3 so that all stays in default.css
The important thing here is that the browser specific files are included after the default. This allows me to specify that a div shouldn’t be a float but instead should use relative positioning or whatever specific tweak is needed.
I feel that this yields much clearer CSS than the hack approach and is hence more maintainable. This also allows us to completely overhaul a design for a particular browser if it is giving us substantial grief. The disadvantages to this approach are that it increases the number of files to maintain.
My personal view is that I would rather have 4 clear and easy to maintain files rather than 1 hard to maintain file.
But, isn’t this unreliable? Couldn’t a user fake this? (Or, a firewall). Sure. However, we’re trying to be pragmatic here – we can’t get a complex page to work 100% reliably on all browsers without doing CSS tricks so we have to do something that is maintainable.
If we keep as much as possible in the core stylesheet then the user shouldn’t have a terrible experience if their browser is mis-reported and so we shouldn’t be losing too many visitors to bad browser detection. We can even go one step further and ensure that the core style sheet gives a good (not perfect) view of the page in every browser without additional tweaking… then layer the tweaks on top!
In the above I have outlined a method that may or may not be appropriate for your situation. If you have a little site with one page, a simple layout but it doesn’t work in all browsers then you’re probably better off using hacks. If you have a big site with lots of pages and a complex layout then you may want to consider layering your stylesheets.
As with all software development – use your brain. Read around. Make the decisions that are right for your project – never use a fork to eat soup.