Cross-Browser Compatibility: Which Browsers Matter?
In a wonderful world the topic of browser compatibility wouldn’t exist — all would adhere to the same standard. However, such a world doesn’t exist and those working on the mobile platform feel the frustration more than most; almost like it’s 1999 again. But in the context of the web based browsers; it is odd that the the question (or debate) of browser compatibility comes up so often. The answer seems so simple — does it really need to be answered time after time? Is there anything worth debating? What browsers matter? I will tell you … check your statistics! Know your user base and build to accommodate that user base; simple.
If 90% of your user base uses Internet Explorer 6, then guess what — you should be ensuring that your site renders properly in IE6 (whether you like it or not). Know your users and then you’ll know the answer to the question; what browsers matter.
Okay, so there might be a bit more to it than that; but not much more. You need a base browser to build off of — one whose default rendering is as close to perfection as possible. This is a debatable topic in of itself; because all browsers have their flaws. However, the Mozilla based browsers (ex: Firefox) have been deemed the closest to perfection at present time — again, this is debatable. So, you build to ensure your mark-up is correct first — this means if you agree with the Mozilla browser, you make sure it works there first and then correct for the other (more flawed) browsers.
So, if 90% of your user base is on IE6 — this does not mean that you build on IE6; it simply means you build your website correctly and then account for the flaws in IE6. We recommend using conditional comments to accomplish this.
The objective is to produce perfect code — as flexible and as extensible as possible. Then, check your site statistics and determine which other browsers are worth the time and effort.
It is for you, the site owner, to determine what % of your user base constitutes enough to warrant spending the additional time/resources on correcting for older more deprecated browsers. At the end of the day, it all comes down to opportunity cost. Accounting for IE7 typically doesn’t require much work — while accounting for IE5.2 on the Mac requires an extreme amount of attention to detail. So if 10% of your user base is using IE7, I would recommend accounting for that user base; because the time/cost is worth not alienating that percentage. However, if 10% of your user base is using IE5.2 on the Mac then I may advise you to not account for that user base — the time/cost might not be worth satisfying that user bases’ user-experience to perfection. The reality is that anyone browsing the modern web on something as archaic as IE5.2 is probably use to a broken web experience in general. But, that is a decision to be made on a case-by-case basis after an extensive review of the site analytics.
And if you are a new website with no past analytics? Well, like with all thing business — do your research. Know your demographic and their web behaviors — check the competition. In general though — always check against the Mozilla based browsers, Opera, Safari as well as IE6 and IE7 (yes, I know there are more).
This same solution goes for the screen resolution debate as well — know your demographic and accommodate them; check your analytics.
To the front-end developers out there … just have pride in your work. Forget the analytics for a second; strive to create perfect code and in that many of your browser compatibility issues vanish. Demand that your code is going to render correctly to the pixel in all modern browsers for no other reason than because it makes you smile!
Posted by Martin Ringlein on November 29, 2007 | Permanent Link |
After looking over the last two months of data from work (government) our website breaks down like so:
63% – IE (mostly Windows XP using IE6)
21% – Spdiers (mostly Yahoo)
8.7% – Netscape
3.6 % – Firefox
3.7% – everything else
Now that most of the web pages on our website are in the same look and feel, I don’t have to worry to much now about things breaking or looking bad. I mostly did my building using IE6, since that is what the government employees must use.
I think a good part of the non IE numbers are from us (web developers) testing that the pages work fine in other browsers.
Thanks, for making me look over our numbers.
No problem — yeah … IE is going to be power house for some time still; just the realities of the market share.
I started writing this a few days ago, but then didn’t finish it:
The debate on “landmark web designs” has surfaced a number of issues central to the philosophy of web design, and you mentioned your take on one of them at the end of this post: whether a web browser is an interface or a canvas.
You suggested pixel-precision in all modern browsers. If a web browser is a canvas for art, then pixels might matter (depending on the artist). If a browser is an interface tool, a pixel probably doesn’t matter — a bug that blows away the layout of a page probably does, but a single pixel usually doesn’t.
I tend to land on the interface side of the debate, even though I care a lot about the integrity of a design. I’m just kinda riffing here, but web browsers aren’t developed for pixel precision and standards don’t spec pixel precision in many cases, so it seems like an unreasonable expectation that they would all respond well to that kind of control.
Instead, my rule of thumb is that browser support should degrade gracefully — it’s a common concept in scripting, but equally applies to markup as well. It might be exactly what you want in Firefox or Safari or IE7, and might differ in other browsers, but as long as the interface is still as usable as practically possible, small browser indescretions don’t bother me, and I don’t think that’s a bad thing.
In other words, spending three hours to hunt down bugs that shift text three pixels that no one would have noticed doesn’t seem like a good use of time to me. But if the point of the site is artistic, then maybe I’d revise that statement.
Jackson, I think you make a great point. Sometimes I come at it from a design perspective and demand pixel precision. I demand this even more when I am coding my own demand — it is the challenge to design something beautiful and have the code be just as beautiful. I do tend to look at the browser as a canvas.
Does 3x matter, probably not. When I code, I try and get it pixel perfect — but will sometimes have to make the judgment call (looking at the opportunity code) to sacrifice pixel precision in the effort of time (increases in time can usually lead to increases in personal stress/frustration and budget).
I highly agree with your suggestion of ensuring code for browsers degrade gracefully! Excellent point to bring up.