The title is a question I ask because I hear so many different views and perspectives about HTTP compression from the people I work with, colleagues and customers alike.

There appears to be no absolute statement about the compression capabilities of all current (or in-use) browsers anywhere on the Web.

My standard line is: If your customers are using modern browsers, compress all text content — HTML (dynamic and static), CSS, XML, and Javascript. If you find that a subset of your customers have challenges with compression (I suggest using a cross-browser testing tool to determine this before your customers do), write very explicit regular expressions into your Web server or compression device configuration to filter the user-agent string in a targeted, not a global, way.

For example, last week I was on a call with a customer and they disabled compression for all versions of Internet Explorer 6, as the Windows XP pre-SP2 version (which they say you could not easily identify) did not handle it well. My immediate response (in my head, not out loud) was that if you had customers using Window XP pre-SP2, those machines were likely pwned by the Russian Mob. I find it very odd that an organization would disable HTTP compression for all Internet Explorer 6 visitors for the benefit of a very small number of ancient Windows XP installations.

Feedback from readers, experts, and browser manufacturers that would allow me to compile a list of compatible browsers, and any known issues or restrictions with browsers, would go a long way to resolving this ongoing debate.

UPDATE: Aaron Peters pointed me in the direction of BrowserScope which has an extensive (exhaustive?) list of browsers and their capabilities. If you are seeking the final word, this is a good place to start, as it tests real browsers being used by real people in the real world.

Once again it is time to analyze browser usage in the US for the last month. July saw the appearance of Firefox 3.5, which has replicated the pattern seen with Internet Explorer 8, where it supplants the previous version slowly and linearly as people get around to upgrading.

Can MSIE 8 overtake MSIE 7 in August? How much will Firefox 3.5 usage grow in August and will it replace FF 3.0 as the dominant version in the Firefox family?

As with previous analyses, Internet Explorer 6 retains its iron grip on the corporate, custom Web application market. The question is not when, but if, this browser will actually fade away. It is unlikely that Internet Explorer 6 will disappear until Windows 2000 and Windows XP percentages are in serious decline.

This points to a larger concern that organizations will have to face within the next 18 months: What do they do when the Windows 2000 lifecycle terminates in July 2010 and as Windows XP sees fewer updates moving toward lifecycle retirement in 2014? [See the Microsoft LifeCycle information here]

Hiding from the inevitable just makes changes that much more dramatic and difficult.

It is not likely that the patterns in the StatCounter data will change until the summer vacation season is over in the US, and students bring their shiny new computers online at the start of the school year.

Here are the browser stats for Newest Industry as of March 14 2009. Not a large amount of traffic, but it is indicative of what most folks with technical content on their blogs likely see.

What did surprise me was the number of people who are still using MSIE 6.0. I am not sure what is continuing to perpetuate the presence of this percentage of people on this antiquated browser, other than large corporations running this by mandate of the IT department.

I think that with the release of all the new browsers this year, support for MSIE 6.0 should simply cease. I will gladly install a javascript library that will kill pages for MSIE 6.0 visitors, announcing that the Internet is no longer available to them.

Last fall it was Chrome. Now it’s Safari 4 Beta. Soon it will be Firefox 3.1 and IE 8.

Each browser has its harsh critics and fervent supporters. But in the end, does the browser really matter?

The answer to this question depends on who you speak to. Developers will say yes, because browsers make their lives hell, as none of them subscribe to the same set of standards for display, rendering, or code processing. I would bet that if you asked any developer, they would prefer that only one browser existed and was used by everyone.

The people at the end of the browser chain, you and I, don’t really care either. We only care when the browser drops an unexpected rendering surprise on us, or doesn’t work because the Javascript functions were designed with Browser A and B in mind and we use C and the submit button on our purchase doesn’t work.

The question isn’t Does the browser matter? but Why does the browser still matter?

There is no reason to have five large browsers out there. There is no reason why they should all behave differently, render pages in their own unique way.

And while people will say that having multiple versions of multiple generations of uniquely developed browsers drives innovation and prevent stagnation in Web development, I say enough is enough.

There is no reason to have yet another browser. The browser doesn’t matter.

The content matters.

And when you switch the perspective around to that view, you should easily realize that the browser, any browser, is simply a window into the content being created for and by us. It should not matter to anyone that I use Opera, Safari, Firefox, IE, Camino, Chrome, or Lynx.

What does matter is that the content can be delivered to me the way I want it. Not the way the browser wants it.

What we need to realize is that browsers no longer matter. They are software. They are portals into what we are trying to do and say.

The browser is not the application; the Web is the application.