Supporting legacy browsers

I don't have access to the browser stats related to my web sites, so I have to get this kind of information from another source, such as search engine sites or page ranking services. The problem with these sites is that they provide only information about the number of visits within a given time range.

However, these sites also report the geographical area my visitors belong to, and I have to say that this kind of information is very useful. I've found out that the majority of my visitors come from Italy (about 60%), followed by a significant number of English and American users who share the remaining 40%. That's fine, but the underlying problem remains the same: I don't know what kind of browser they use.

Since my sites are about web standards, it's likely that my visitors may use a full standard compliant browser, such as Firefox, Safari or Opera. That's true if we consider my visitors only as colleagues, but it might be false if we take into account also clients. In fact, clients may surf the web with a legacy browser (Internet Explorer 6, or even worse) and when they find your site broken, they may think: "so you're a web developer, huh? Fix your own site first!".

In that vein, I followed a radical approach with CSS Zibaldone by keeping structure and layout as simple as possible. The result is practical but ugly: don't follow my example if you want to get some interesting jobs! So I decided to create a stronger structure and a finer layout for this web site. To accomplish this task, I wrote down a practical browser testing order, which includes:

  1. Firefox
  2. Internet Explorer (6, 7, 8)
  3. Others (Safari, Opera, Camino, etc.)

The order is relevant: when I test a site, first I view my results in Firefox, then in Internet Explorer and finally (only finally!) in Safari, Opera, Camino, etc. Supporting legacy browsers such as IE 6 means only one thing: testing, testing, testing!

As a rule of thumb, never trust the results achieved on your local machine, because IE behaves differently on a remote server (this is particularly true for Ajax and any XML-based language). And remember: test first, fix later.

Leave a Reply

Note: Only a member of this blog may post a comment.