Accurate Browser Statistics?

zyl0x asks: "A co-worker of mine has been made responsible for a large web application for our software product, and he was having a hard time deciding what functionality to implement, and whether or not to sacrifice functionality for a larger user base. With Walmart's harsh stand on browser compatibility, we got to thinking, exactly how many users would we be alienating by using some IE-only functionality on our website? We tried crawling the internet to get some current, accurate browser usage statistics, but we could only find stats for specific websites. I thought I'd try sending Google a request, since we imagine they'd have the lowest-common-denominator in terms of types of users, but I received an email from their press department telling me that they 'don't make that kind of information available.' Where can one get a current, accurate, and un-biased measurement of browser usage? Is it even possible?"

Comments

Depends on your audience

[Kelson]

Browser marketshare varies widely according to audience. And by audience I mean not just people's interests, but their geographic location. Opera is used more in Europe than North America. Firefox is used more by visitors to techie sites than by visitors to entertainment sites. I've got one site where Firefox accounts for 20% of visitors, second to IE at 70%, and another where Firefox is #1 at 44% and IE is #2 at 40%.

Firefox, the second-most-used browser, seems to have a marketshare of 10-20% depending on where you look. So you'll probably be blocking at least 10% of potential users, if not more, by restricting your site to IE users only. And that percentage continues to grow.

Keep in mind also that IE is only available on Windows (not counting emulation, which is of limited use). The Mac version has been discontinued. Unless you want to block all Mac users, you'd better provide at least Safari or Firefox compatibility.

Also, any site that already restricts browser access is going to have skewed results, because the potential audience using other browsers has either cloaked their browser to look like the supported one, or has gone somewhere else.

Since you say this is a new application, you'll want to get statistics from a similar product that works cross-platform.

Re:Depends on your audience

[99BottlesOfBeerInMyF]

Browser marketshare varies widely according to audience.

I'll second this. I do a little work on a Web based interface to a security product for very, very large network operators who can afford to shell out the big bucks. A major portion of our interface was nonfunctional in IE for about a year and a half before anyone noticed because all our customers use Firefox or Safari or Opera or Lynx. If you're actually trying to find information that is practical for your application you need to look at your market segment and similar sites.

Also, any site that already restricts browser access is going to have skewed results, because the potential audience using other browsers has either cloaked their browser to look like the supported one, or has gone somewhere else.

Yeah, IE only sites skew numbers because people fake it or go elsewhere. Likewise, sites that are defaults for a browser (like Google for Firefox or MSN for IE) will have results skewed towards that specific browser, so Google's numbers would not have been all that useful to you. Look for a Web site that targets the same demographic, but does not have any of these factors to muddle the numbers.

I'd also like to echo other people here in voicing another argument against IE specific Web services. No one knows what the market share in five years is going to look like, and ripping out your working solution because IE is down to 50% would be a horrible snafu. Further, as more and more devices start to provide Web browsing capabilities, like phones, PDAs, PVRs, and televisions, standards become more and more important. Your company itself could standardize on Linux from some vendor in the next 5 years. It doesn't hurt to be a little forward thinking and keep your tools flexible. There just isn't much you could not implement to be cross-platform if you have a competent developer, and if you don't you're likely to have all sorts of other problems as well.

Re:Depends on your audience

[jimstapleton]

Very good poitns here.

Also, I know Safari is based off of Konqueror, and both are pass ACID2 (I think Opera does as well?)

So by having one of these in your compatability list, that should implicitly add the rest, even if all are a relatively lower market share compared to IE/Firefox.

Re:Depends on your audience

[MaggieL]

Browser marketshare varies widely according to audience. And by audience I mean not just people's interests, but their geographic location.

Not to mention IQ and gullibility index.

Re:Depends on your audience

[great throwdini]

Also, I know Safari is based off of Konqueror, and both are pass ACID2 (I think Opera does as well?)

So by having one of these in your compatability list, that should implicitly add the rest, even if all are a relatively lower market share compared to IE/Firefox.

This reasoning is nonsensical. The relation between "passing ACID2" and real-world site development isn't automatic. The scope of the ACID tests is narrow, and it's a trivial exercise to produce content that adheres to existing recommendations that browsers "passing ACID2" handle in varying and deleterious fashion.

Re:Depends on your audience

[evought]

Browser marketshare varies widely according to audience.

Another thing to consider is the reverse: audience may vary by browser. For instance, some studies have shown that Mac users spend more on software and peripherals per capita. Certain categories of users may have different amounts of disposable income and different amounts of interest in your product and that may be correlated to browser use, so alienating certain categories of users may have more (or less) effect than the raw percentages suggest. I would suggest being very careful before considering a business strategy which includes standing at the door to your store and telling one in ten or even one in twenty of your customers that their business is simply not wanted. Consider a bank drive up which did not do business with customers who drive up in a Mercury.

Re:Depends on your audience

[mwvdlee]

So to sum it up:

If your site is called "IEBugFixes.com", you'll probably have 99% MSIE visitors. If your site is called "FirefoxPlugins.com", you'll have 99% Firefox visitors.

Just run your own browser statistics or try to find out the browser statistics for your closest competitors.

The real important question is; what MSIE-specific features would you want to include, and do they really improve your site?

Re:Depends on your audience

[jonadab]

> I've got one site where Firefox accounts for 20% of visitors, second to IE at 70%,
> and another where Firefox is #1 at 44% and IE is #2 at 40%.

Furthermore, neither of these is a particularly extreme example. It's not hard to find examples of sites where IE usage is over 95%. (Usually these are sites that have historically depended heavily on ActiveX for important parts of their functionality, but not always.) On the other end of the scale, the stats for catalog.galionlibrary.org are more than 75% Firefox. (This isn't entirely fair either, because every computer in the library, including six dedicated ones that can *only* access that catalog, have Firefox.) Sites directly related to browser issues can be even more skewed. Windows Update probably gets 99% IE or higher; whereas, things like Mozillazine and spreadfirefox.com and addons.mozilla.org would be expected to have abnormally high Firefox usage figures, due to the nature of what the site is.

Your IE/FF figures of 70/20 and 40/44 are actually plausible for (relatively) normal sites that will work properly in all the major browsers and don't actively promote or relate to any one of them.

Re:Depends on your audience

[Kelson]

Your IE/FF figures of 70/20 and 40/44 are actually plausible for (relatively) normal sites that will work properly in all the major browsers and don't actively promote or relate to any one of them.

For the record, the 70/20 site is Hyperborea.org. The biggest draw there is a comic book fan site I've been running since 1996, which gets a mainstream, perhaps slightly geeky audience. It also contains my blog, some photos from conventions, my wife's website, and some smaller sites I built back in college. The 40/44 site is the Alternative Browser Alliance, a site promoting the use of non-IE browsers and cooperation (or at least civility) among their supporters. Most of its traffic comes from searches for alternative browsers, from technically-oriented sites, and from (interestingly enough) StumbleUpon.

Re:Depends on your audience

[the_womble]

My experience is much the same.

My main site gets about 80% IE. However, there has been a significant drop over the last year (from over 90%) - rather to my surprise given the audience (UK oriented and a lot of people read it at work).

On the other hand, my blog gets about 55% IE. While not a techie blog, it does have pages on my Wordpress themes and plugins, and a fair amount of content that might appeal to a techie audience.

From a financial point of view, if this is revenue generating, and operational gearing means that losing 10% (its not going to be much less) of users, could mean losing a lot more in profits. Losing 20% or 30% of losers is likely to lose you a lot of your profits.

Re:Depends on your audience

[Anonymous Coward]

If the Mercury were four feet wider than the lane it needed to drive through, and the majority of customers were predominantly driving cars that would fit through that lane while the bank would have to spend more to widen it, doesn't it better financial good sense to keep the lane the width it is? /devil's advocate.

These aren't the browser stats you're looking for

[Tumbleweed]

Unless you are Google, don't worry about what Google's browser stats are. Instead, look at the browser stats of your OWN web site. Those are your customers.

I''ll mostly refrain from talking about the monumental stupidity of using IE-only functionality because I know the Slashdot crowd will be (justifiably) beating your head in over that momentarily. Good luck with that.

It almost doesn't matter what percentage...

[ivan256]

Is 1% of your expected revenue greater than the implementation costs of supporting multiple browser platforms?

For almost every site out there, the answer to this question is "Yes". If you are in that situation, it would pay for you to use technology that would work on all browsers, or have a browser specific page with equivalent functionality for non-IE browsers. You often see Slashdot comments in these types of threads that say the "extra 5% of the market is too small for the company to care about". Sure, 5% seems small, but the costs of developing cross-platform support for web applications is usually so low that you're throwing away free profit by ignoring even the least-used browsers.

There are other arguments too... Many IE specific features are annoying even if you are an IE user, Using technology that isn't standardized across the industry make maintenance more difficult across platform versions, etc... But really it comes down to the money.

Re:It almost doesn't matter what percentage...

[Anonymous Coward]

I don't think I'd go quite as far as supporting the least-used browsers personally (too much testing, too much browsers and OSes out there), but developing for all the main ones is rather easy (and not that expensive).

I develop for/using firefox primarily (mainly because of all the dev tools, like the web developer toolbar, firebug, etc), and use hacks where necessary to make it work in IE. Then we test on most of the others (opera, konqueror, galeon, epiphany, netscape, etc), and they almost always all work fine on the first attempt.

But testing for lynx, webtv and things like that? No way. We never see anything like that in our logs, and I believe there's a limit to how accommodating one can be to esoteric platforms. It's THEIR choice to use something weird, and they have to put up with the consequences. We develop using standards, and test using perhaps more browsers/platforms than we should bother with in the first place. If they chose something else that's not so much standards compliant and doesn't work right, it's their own fault, and most likely 99% of the other websites don't work right on that either.

Re:It almost doesn't matter what percentage...

[dvice_null]

> But testing for lynx, webtv and things like that? No way.

Testing with Lynx is actually quite a good idea. Not only will you make sure that blind people can see your site, you can also confirm the complexity of your website and how easily information can be found from there.

Re:It almost doesn't matter what percentage...

[Johnny Mnemonic]

It's THEIR choice to use something weird

It's YOUR choice to ignore customers. If the support and dev costs for WebTV is less than what you'd gain by including them as customers, you're simply making a bad business choice. Serving customers and making sound business decisions is usually not about convenience.

Re:It almost doesn't matter what percentage...

[FLEB]

I don't know as if I'd go as far as developing for Lynx, but it's definitely good to see that your site maintains some sort of semantic sensibility when viewed in Lynx-- when you're using it, you get text and only text, and that's how screen readers and (most importantly) search engines will be reading your pages.

Re:It almost doesn't matter what percentage...

[kv9]

Testing with Lynx is actually quite a good idea. Not only will you make sure that blind people can see your site, you can also confirm the complexity of your website and how easily information can be found from there.

blind people use lynx?

Re:It almost doesn't matter what percentage...

[Mr. Shiny And New]

Is 1% of your expected revenue greater than the implementation costs of supporting multiple browser platforms?

The answer is more complicated than the question makes it seem; remember that the implementation costs to support a new browser could be spent on adding new features that will grow your market for existing users. Thus you have to say, "What does it cost to support another browser? What else could I spend that money on? Which gives a better return on investment?" If I can spend $1000 to add support for one more browser on my website, and that will net me $10,000 in sales, vs. spending $1000 on adding new features to the site which will net me $20,000 in sales, I think the answer is clear that the other browser isn't going to be supported this iteration.

Re:It almost doesn't matter what percentage...

[ivan256]

Actually, the answer is clear that unless you're strapped for cash, you do both.

Asking whether you should do one thing or the other when the two things aren't mutually exclusive makes for a great strawman in an argument, but has no bearing on reality.

Re:It almost doesn't matter what percentage...

[ChristTrekker]

Maybe not, but it is a decent simulation of their experience for the sighted person. Whatever you see in Lynx is what they will hear. Pare your site down to text only - that's what aural browsers (and Lynx) do.

Re:It almost doesn't matter what percentage...

[Mr. Shiny And New]

Even if you're not "strapped for cash", the only time you do "both" projects is if you only have two projects. In practice there are ALWAYS multiple ways money can be invested to get a return, including investing that money in bonds or putting it in a bank account, and a company has to look at all ways it can benefit from that money. If adding support for a marginal browser would give a 1% ROI, but investing that SAME MONEY in a bank account gives 2% ROI, the business would be foolish to add the support for that browser. It's not a strawman, it's reality.

Re:It almost doesn't matter what percentage...

[ivan256]

Yeah, you're argument isn't a strawman if you change your argument. (Actually it is, since your new argument includes a strawman too)

In reality it's neither as simple as your most recent comment or as my initial comment make it out to be. For example: A better net ROI doesn't necessarily make one decision better than another for many reasons. For example, a net increase in revenue with zero overall ROI will probably be a better choice for a venture backed startup than having the investors money earn interest in the market. But these are all ridiculous things to consider because they are outside of the context of the original discussion.

If the question is "Is it worth supporting a browser that has a non-majority market share?" without any additional data, the answer boils down to whether you will get more out of the support than you put into it. If you're going to presume options that aren't implied or mentioned directly in the question then why not ask whether they would be better off investing their development dollars in something other than a web application?

Re:It almost doesn't matter what percentage...

[Anonymous Coward]

Thanks for mentioning that, I haven't tried my sites in Lynx for years.

Turns out Drupal looks great in Lynx, just like it seems to for everything else. It's a very well-done CMS.

OS X users, get Lynxlet

http://macupdate.com/info.php/id/22856

Re:It almost doesn't matter what percentage...

[Mr. Shiny And New]

Well, I'll agree that if the question is "Can it be worthwhile to support other browsers in some circumstances", then the answer is simply "yes", however I think it's pretty clear that we're talking about a business running a website, and it's a pretty safe assumption that a business has limited developer resources available for adding new features, and these features (one of which is additional browser support) need to be prioritized. Maybe you work in a company where there are tons of spare dev and test cycles to go around, and you have time to support every browser you want to support, but I work for a major website and I can tell you it's hard enough supporting the main browsers 100% all the time, let alone minor browsers.

Believe me, I'm all for nice, cross-platform designs that work well in lots of browsers, and I wish every website looked awesome in lynx AND every version of IE and firefox, but the reality is pretty basic: there just isn't time. And the reason I brought this up in the first place is that Slashdot discussions about this topic often forget that simple economics drive many of these seemingly strange choices when it comes to browser support. Mac support? Why wouldn't you want to support Mac users? Because it's not a profitable decision at this time? Exactly. Maybe the economic analysis is wrong, but maybe a site that looks like crap in Safari is the right thing to do for your shareholders, as unpopular as that makes you in the Mac world.

Bad faith

[Rob T Firefly]

The reason there is such a thing as IE-only functionality is the fact that one powerful company wants to break the open platform and force people onto theirs, in order to fill their own pockets. This is not something I wish to support in the least, so I don't create, use or promote any web-based things that require IE.

Re:Bad faith

[Anonymous Coward]

I've taken it 1 step further by inserting some HTML known to crash I.E. in my top level page.

If they skip the top page, my picture gallery doesn't work with I.E. for some reason that I haven't bothered to figure out. Not my problem since I follow normal HTML standards.

Yes, I am easily amused. I recognize this.

Compatability still a big problem?

[LighterShadeOfBlack]

Just curious, what kind of IE-only content are you talking about here? Granted I've never developed a commerical web app but I haven't come across any major obstacles to implementing cross-browser functionality in anything I've written in recent years. OK so I usually end up with a couple of dozen IE-specific fixes that have to be made and maybe some browsers get less functionality than others but I've not come across anything which worked on one browser that couldn't fail gracefully on another.

Or am I just being ignorant in thinking this isn't really a major problem anymore?

Re:Compatability still a big problem?

[hobo sapiens]

Or am I just being ignorant in thinking this isn't really a major problem anymore?

It shouldn't be. These days, coding websites for IE only reflects the web developer's utter lack of current knowledge. It's like saying "Help me! I seem to have fallen in 1997 and can't get up!" It takes virtually no extra work to write stuff cross browser (or at least close enough), and if you think it does take too much work then your skills aren't what they should be. Just use web standards. Couple that with the good ole KISS* principle, and presto. Anyone who doesn't get that should never ever again write another web interface, IMO.

*you know: Rock and Roll all night, Party everyday! (yes, I couldn't resist)

Re:Compatability still a big problem?

[AKAImBatman]

It takes virtually no extra work to write stuff cross browser (or at least close enough), and if you think it does take too much work then your skills aren't what they should be. Just use web standards.

Correction: It takes virtually no extra work to write stuff for all browsers except when you need to support IE for non-trivial work. Getting things working in IE is a pain due to its lack of standards support, and shouldn't be necessary. Thankfully, it's possible to maintain a small list of Javascript and CSS patches that can take care of 95% of the issues. The rest can be fudged so that IE works "ok". It's just that it's not pleasant to do things like maintain an IE-specific style sheet.

Re:Compatability still a big problem?

[hobo sapiens]

thank you for the refinement. damn straight!

Re:Compatability still a big problem?

[Student_Tech]

I'm not sure if this is an IE-specific, but it does limit who can use their page.
OK full details:
1. Mom finds sight that sells stuff to only retailers (not a problem as she runs a store and this would be good for the store).
2. Fills out stuff, gets a username and password.
3. Go to sign in, prices don't work. She complains and they ask what version of IE she is running? (She's running Firebird 0.7 aka Firefox 0.7 IIRC)(It's a Win95 machine that my parents don't feel like moving off of quite yet. It is hidden behind a firewall)
4. I look at it. Sign in page is located like "/sys/login/" or something.
5. When You login the cookie sent back from their server has "path=", So no path. (Yes, it has "path=;" in it) Spec I can find (and Firefox and Opera seem to follow) is that if no path is specified, then you use the path of the page. IE does something else.
6. Attempt to view page with prices located at like "/catalog/". IE shows prices because it is sending the cookie. Firefox and Opera don't send the cookie because the path is different.
7. We email back to them what I found, haven't heard anything back yet.

At least, this is my best guess as to why the prices show up in IE (tested with 5.5 and 6, don't have access to 7), and not Firefox or Opera.

An IE requiring site because of the way the path in the cookies is set.

Re:Compatability still a big problem?

[davido42]

I wrote my code using alleged "web standards". I used Firefox as my development browser. I'll give you 1 guess as to which browser was not compatible with my code. (Hint: starts with the letter 'I' and ends with the letter 'E')

To be fair, it is more accurate to say that IE was not as resilient to my bugs as Firefox and the other browsers (Safari and Opera were also tested). It's still not completely compatible, but I bludgeoned it into submission so that IE is functional. I'm really looking forward to checking it out on Mom's Win98 machine. Ugh.

http://www.bitworksmusic.com/

Re:Compatability still a big problem?

[hobo sapiens]

Welcome to life as a web developer. IE sucks. Repeat that like a mantra and you'll get by just fine.

In all seriousness, you will in time learn what to do and what not to do in order to appease IE, the worst piece of software ever invented. Stay the course and code to standards and 99% of the time you'll be just fine.

This is also why I alluded to the KISS principle: if you can, avoid complex stuff. Less for IE to break. Part of coding to standards is, at least in spirit, simplicity.

For times when you just have to get fancy, you just have to learn what IE wants. An example: building table rows via javascript. didjaknow IE *REQUIRES* that you use a tbody tag when appending table rows? IIRC failure to do so won't give you an error, but it sure won't work. So before you get happy and appendChild(myrow) into the table, you gotta have a a tbody. Not sure if that's a misinterpretation of standards or what, but no other browser requires that you do this. Again, that's what sometimes happens when you get fancy. Far worse would be to avoid standards and use IE-only code. Strictly speaking, one could argue that what I mentioned has little to do with the standards you use when writing markup. True, but it does illustrate that IE is a very odd browser. Good web developers have to take the shotgun approach and code to standards, and then fill in the holes IE creates for you. And Microsoft shows little interest in fixing things. They have the market share and to hell with everyone else including the people who develop the software that runs in their browser. I hope IE gets displaced very soon, but I am not optimistic that it ever well.

The short of it: blame IE and not the standards. Learn to deal with it.

Re:Compatability still a big problem?

[8-bitDesigner]

Now, I wouldn't say that it's just as easy as "Use web standards" as IE6 does a good job of buggering that up. Honestly, it requires a bit of time and dedication, and depending on the complexity of your layouts, a near encyclopedic knowledge of IE6 specific bugs and accoutrement workarounds, but it's sure as hell worth the effort when you're re-laying content and adding new pages daily.

Re:Compatability still a big problem?

[anomalous cohort]

Getting things working in IE is a pain due to its lack of standards support

There are lots of folks who have already incurred this pain for you and have written books and/or javascript libraries that you can use to mitigate the pain.

Re:Compatability still a big problem?

[Bogtha]

So before you get happy and appendChild(myrow) into the table, you gotta have a a tbody. Not sure if that's a misinterpretation of standards or what, but no other browser requires that you do this.

That actually sounds like every other browser has it wrong and Internet Explorer has it right (yes, in certain rare occasions, it has been known to happen). In HTML, every table with one or more rows has a <tbody> element. Just because the tags aren't in the HTML, it doesn't mean the element isn't there. <tr> elements cannot appear as direct children of <table> elements, the HTML parser understands that there is an implied <tbody> element and inserts it automatically. This is correct behaviour. If you don't believe me, start Firefox, open a test page, and fire up the DOM inspector. The <tbody> element will be there.

Now, that's all well and good, but the DOM doesn't have any concept of implied elements. That's a feature of the HTML parser, not the DOM. So if you are trying to table.appendChild(row), then it literally means that you want the row as a direct child of the table. That's not correct HTML.

Re:Compatability still a big problem?

[hobo sapiens]

Interesting. I figured that the thead/tbody/tfoot were optional. However, using Firebug's DOM inspector (If you don't use Firebug for Firefox, get it!), I see that the tbody is implicitly created despite the fact it's not in the actual source code. Oddly enough, thead and tfoot are not. But that does seem to support what you are saying, namely, that the HTML parser implicitly creates it. Personally, I don't like implicit in cases like this. Anyhow, I think you are right.

Well, then here is yet another argument in favor of confining your coding practice to one browser. Writing code for just one browser is bad regardless of browser.

Re:Compatability still a big problem?

[Bogtha]

I figured that the thead/tbody/tfoot were optional.

Well <tbody> is optional in XHTML, and <tr> elements can appear as direct children of <table> elements. This is one of the things that trips up people who think that the difference between HTML and XHTML is just in the error handling, lowercase element type names and closing every element explicitly. The following code actually means different things depending on whether it's parsed as HTML or XHTML:

<table>
<tr>
<td>...</td>
</tr>
</table>

That's why, if you are writing XHTML, you actually have to test it in both text/html and application/xhtml+xml modes before you can say with any confidence that your code is bug-free. Sure, validation helps, but a validator isn't going to catch when your JavaScript expects a <tbody> and it's only there when you serve your pages as text/html.

Re:Compatability still a big problem?

[awful]

Seems like it is if you live in South Korea...

Re:Compatability still a big problem?

[3247]

Well <tbody> is optional in XHTML, and <tr> elements can appear as direct children of <table> elements.

You're confused. "<tbody>" is a tag and is optional in both HTML and XHTML. The names of elements are written without angle brackets.

Re:Compatability still a big problem?

[Bogtha]

You're confused. "<tbody>" is a tag and is optional in both HTML and XHTML.

I'm not confused, I just use different delineation conventions to you. Talking about element type names can get confusing when they aren't set apart from the rest of the text (e.g. talking about tables as opposed to <table>s). Just because I use angle brackets, it doesn't mean I'm talking about tags — in the context of the discussion, I'm obviously talking about the element type, and I don't believe for a second you thought I was talking about tags. I mean, what on earth did you think I meant when I said:

In HTML, every table with one or more rows has a <tbody> element. Just because the tags aren't in the HTML, it doesn't mean the element isn't there.

Re:Compatability still a big problem?

[jonadab]

> IE, the worst piece of software ever invented.

IE is certainly not the worst piece of software ever written. It's not even the worst piece of software Microsoft has ever written (Outlook Express for instance has it totally outclassed in terms of overall badness), much less the worst overall (which dubious honor almost certainly belongs to one of those "resume writer" programs you could buy on floppy diskette at college bookstores during the late nineties).

It might reasonably be considered the worst current major web browser, though.

Enter webcomics...

[strredwolf]

Take it from a site that hosts 6000+ webcomics, so you get a good sense of what's being used out there.

On average from CG, from the top of my head (not accurate!!!):

* Firefox/IE are major contenders -- ether one or the other flops back and forth the lead.
* Safari rounds out the third
* Konqueror, Opera, Netscape 4, and web spiders scrape out the distant rest.

What I would do is follow Google Mail's lead: Make a javascript version and a non-js version, and if there's a browser not on the tested whilelist, go non-js.

Re:Enter webcomics...

[CrimsonBadger]

I think that readers of webcomics are significantly more likely to use Firefox than the average internet user.

Re:Enter webcomics...

[Bogtha]

Make a javascript version and a non-js version, and if there's a browser not on the tested whilelist, go non-js.

In the particular case of JavaScript support, this is poor design. Identifying and testing in browsers is a slow, unreliable process, and needs constant maintenance as new browsers come out. It's been best practice for years to use feature/object detection.

use the w3c validation service.

[Anonymous Coward]

validator.w3.org is your friend. if it validates, its good. just do that.

These seem fairly accurate

[jdcool88]

They are certainly not perfect, but it should give you some idea.

http://marketshare.hitslink.com/report.aspx?qprid= 0

Re:These seem fairly accurate

[Bogtha]

How are you judging the accuracy of these statistics? I don't see any estimated error or confidence level. They don't describe their methodology. Are you doing what most people do and considering statistics "accurate" just because they reinforce your existing beliefs?

Is this just because it's easier?

[Anonymous Coward]

Are you wanting to use IE-only functionality because it's easier to implement? The possible loss of revenue by not providing service to people who aren't on IE is probably enough of a reason to spend the extra development time. That's just one initial cost, and maybe some extra maintenance if it proves to be tricky to maintain, but it means you've openned yourself to what could amount to a large amount of revenue. Of course, it depends on your individual user bases particulars when it comes to Browsers.

I tend to use IE-only functionality only when it's for our Intranet. In that case, I know that every user is running IE, because that's the mandated standard for company computers. They can have FireFox, but they all have IE. And at that point, the extra development can result in a minimal amount of advantage, depending on the situation.

Google may not be the best choice

[jonbryce]

as it is the default search engine for pretty much every browser except internet explorer. A lot of ie users do change their search engine settings to google, but many will stick with live.com or msn.

More than Firefox

[Kelson]

I forgot to mention in the first post, that it's more than just Firefox growing. Safari and Opera may be relatively small, but they're gaining as well. And there are quite a few other modern browsers around. You can expect several of them to grow over the next couple of years, probably at IE's expense.

So even aiming for just IE+Firefox support isn't enough to be sure that you're not still turning people away. Fortunately, many of the lesser-known browsers share the same rendering engine (or a variation thereof) with Firefox or Safari, making it easier to keep compatible. You basically have to target the standards and test in Gecko, IE, Opera and KHTML/Webkit.

Re:More than Firefox

[JuliaNZ]

Safari and Opera may be relatively small, but they're gaining as well.

I don't see this. I look after about 20 recruitment websites in Australasia across a number of industry sectors. (The sites are almost all designed and tested for a wide range of browsers, screen sizes and platforms so I'm not trying to exclude anyone at all.)

IE is still a solid 85-86% on our sites, with Firefox breaking the 10% barrier recently. Firefox has been slowly and steadily growing in an almost perfect linear fashion during the whole time I've been running these sites, but a fair bit of that growth seems to have come at the expense of other "alternative browsers". Things like the Mozilla suite and Netscape 6+ are dropping completely off the graphs now. Opera now barely ever registers more than half a percent, and Safari has been fixed at about 1.6 - 1.8% for a long time even though Mac usage has (just) broken the 2% mark.

Re:More than Firefox

[mgblst]

I don't see this. I look after about 20 recruitment websites in Australasia across a number of industry sectors. (The sites are almost all designed and tested for a wide range of browsers, screen sizes and platforms so I'm not trying to exclude anyone at all.)
 
Ahh, but as the poster says, you need to look at the audience. So, your statistics tell us what the unemployed use. This begs another question, is there any correlation between being employed and using Firefox? (nobody gets fired for using Firefox!)

Re:More than Firefox

[JuliaNZ]

Probably the opposite, there's extremely low unemployment in NZ and Australia at the moment. I've always assumed that our generally lower rates of Firefox/Safari/Opera et al compared to other stats I've seen is partly that a large percentage of people are hitting our sites from their current job on corporate machines, which are locked down and running IE (peak times also correlate to business hours pretty well).

Am I missing something here....

[Anonymous Coward]

Whatever happens to standards?
http://validator.w3.org/

You can make anything you like available on a web server. If someone complains, and it follows the standards, then it's their fault. If it doesn't, then it's yours.

Re:Am I missing something here....

[LighterShadeOfBlack]

Responding to the majority of your customers' complaints about your site not working with "aha! but your browser doesn't follow web standards" is a fast way to get rid of all your complaints. And all your customers. The "just use web standards and screw everyone else" viewpoint is not a practical one. Especially if we're talking about a business. Bottom line, most people use IE and most people don't give a damn about web standards, they just want things to work. You don't tell ~80% of your customers it's "their fault" they can't get to your webpage. Or at least you don't if you still intend to be in business a few months down the line.

Having said that, standards are obviously the way to go. As long as you don't do anything too radical IE will follow along for the most part, and generally speaking even when you do push it too far workaround can be made so that everyone can make use of the site even if they don't all get quite the same experience.

Re:Am I missing something here....

[Anonymous Coward]

Maybe you'd have a point if the w3 standards were reasonable, but they're not. For example the standard won't let you write a table-row generator in Javascript: the code has to sit outside a or inside a but not inside a . Gratuitous limitation.

Re:Am I missing something here....

[TheSunborn]

Are you trying to use innerHTML to generate a table? (InnerHTML is afair not even w3c)

There should be no problem trying to do what you want, if you just use javascript to manipulate the DOM directly.

Re:These aren't the browser stats you're looking f

[hobo sapiens]

Dang, and I was gonna beat him over the head, too. Too busy laughing at your reply to beat anyone. Well played.

Standards compliance is cheap.

[SatanicPuppy]

If you follow the standards your site will look good on most browsers, including IE.

On the other hand, if you jump on all the IE specific functionality you have a few issues. Will it work on old versions of ie? Will it work if people have their active X controls set to "high security"? Will IE break your sites functionality in a security upgrade?

Either way, you're writing off Mac's and all cellphones and pdas, you're writing off a lot of /.ers, and pretty much everyone who has a non-ie browser.

Now, I think Walmart gives as much of a shit about me as I do about them (if I were bleeding to death I'd drive 10 more miles to get some bandages rather than go to Walmart), so no loss for either one of us. But your company isn't Walmart, whose main customer base isn't remotely online.

If it were me, I'd stick with standards.

Re:Standards compliance is cheap.

[hobo sapiens]

Standards compliance is cheap

Says it all. I am so sick of the misconception "We are gonna do it on the cheap and make it IE only".

On the other hand, if you jump on all the IE specific functionality you have a few issues. Will it work on old versions of ie? Will it work if people have their active X controls set to "high security"? Will IE break your sites functionality in a security upgrade?

Yes I've seen it all. I have a team member whose coding skills are stuck in 1998 and he writes stuff (on the intranet) that uses all kinds of proprietary IE crap. Every time IE gets an upgrade, or my company implements some new security patch, he has to test everything. Yet he always ridicules others who write using standards claiming that "IE is the company standard browser!". What a fool. Some people never learn.

Re:Standards compliance is cheap.

[poopdeville]

I have a team member whose coding skills are stuck in 1998 and he writes stuff (on the intranet) that uses all kinds of proprietary IE crap. Every time IE gets an upgrade, or my company implements some new security patch, he has to test everything. Yet he always ridicules others who write using standards claiming that "IE is the company standard browser!". What a fool. Some people never learn.

Sounds like he's getting paid not to.

Re:Standards compliance is cheap.

[quinnharris]

I bought into the coolaid that "If you follow the standards your site will look good on most browsers, including IE."
It should read "If you follow standards your site will look good on most browsers, EXCEPT IE."

Being a Linux user I made the mistake of initially designed a site using Opera, Konqueror and Firefox following the w3c recommendations. The differences between how these browsers render are relatively minor and its usually easy to find a good common denominator. Then there is IE, especially 6 but 7 still isn't in the same league as those other browsers. I had to restructure my HTML to get it to work good enough in IE. I wanted a tabular layout for screen rendering for one part but I thought divs would be better markup. This isn't a problem in all modern browsers except IE. And IE 6 had this really weird bug where part of the page background would turn grey when you scrolled the page down then up again. I never seen something that pathological in the other browsers. I shuffled the markup around a bit and it went away.

If you need to support IE, you should test with it from day 1 (it will shape how you implement a site). If you need to support Opera, Konqueror and Safari you can test with just Firefox (following w3c recommendations) and fix the minor problems at the end.

And using a w3c validator is not enough to verify if a page will render right on all browsers. There are many little gotchas in CSS that can vary between browsers, especially with IE.

I personally prefer Firefox for development (firebug ...) and Konqueror for daily browsing.

Re:Standards compliance is cheap.

[Mex]

Not always true. IE7 seems to have some very random broken code where javascript doesn't work.

Yes, Macs

[Kelson]

macs, lol.

Hey, if you want to block millions of potential visitors, that's your prerogative. Personally, I'd like to keep the doors open for them.

Re:Yes, Macs

[99BottlesOfBeerInMyF]

Hey, if you want to block millions of potential visitors, that's your prerogative. Personally, I'd like to keep the doors open for them.

I've always felt that online retailers who neglect the mac Web share are really making a big mistake. Say they are 5% of Web users. Which 5% are they? Well, they are the ones with disposable income who can afford to shell out more for a computer. That means you've eliminated the 40% of Windows users who are pirating it in a country that does not enforce copyright law well. When it comes to potential customers, unless you're selling a product that only works on Windows you are actually cutting out more like 10-15% of your potential customers, and it is one of the most affluent chunks of that total market. It seems like a pretty poor idea to me.

Re:Yes, Macs

[Anonymous Coward]

Yeah but, they wouldn't want my software anyway because it's customizable. They hate that.

Re:Yes, Macs

[Anonymous Coward]

Totally; retailers that block out Mac users are definitely making a mistake.

Don't want to block the all-important "more money than sense" demographic...

Thank you, I'll be here all night. Try the veal.

Re:Yes, Macs

[KDan]

Wtf is wrong with y'all? Haven't you heard of W3Schools? There's your answer:

W3Schools Browser Stats

Full breakdown, data going back to 2002, good selection of sources... what more do you want???

Daniel

Re:Yes, Macs

[Carnildo]

Full breakdown, data going back to 2002, good selection of sources... what more do you want???

Relevance, perhaps? That looks nothing like what I see on my website.

For me, IE6 and Firefox are about 45% each. IE7 is nowhere to be seen. The remaining 10% is split among Safari, Opera, Konquerer, Mozilla, Netscape, Lynx, WebTV, Mosaic -- you name it.

check your own stats

[Anonymous Coward]

check the stats of your current website and the percentages of bowsers being use. Be aware that some browsers have settings to look like another when online.

IE Upgrades

[Kelson]

On the other hand, if you jump on all the IE specific functionality you have a few issues. Will it work on old versions of ie? Will it work if people have their active X controls set to "high security"? Will IE break your sites functionality in a security upgrade?

This is a good point. In case the submitter isn't aware, IE7 removed or disabled a lot of IE-specific functionality relied on by web apps. Functionality based on the standard specs, however, not only worked across IE6, Firefox, and others, but needed minimal adjustment -- if any at all -- to work in IE7.

In my own experience, most of the changes I needed to make with IE7 involved disabling workarounds for IE6-specific bugs.

The important ones...

[RealGrouchy]

Perhaps 'only' 10-20% of your visitors will use non-IE browsers. However, perhaps only 5% of visitors to your website will purchase your product.

Do you want to gamble on which 5% that is?

- RG>

Count users, not hits.

[Anonymous Coward]

I manage all web services for my employer. Not surprisingly, there are many ways to count "browsers" - by hits, by IP, by "user sessions", by "known users", or something else.

I only count "browsers per known user per day". So users that come in more than once per day are only counted once; anonymous users (and robots/crawlers without a credit card in hand) are excluded.

This, not surprisingly, results in a number that's quite different than traditionally published "browser" numbers. The net result is that the browsers I must support are IE6, IE7, Firefox, and Safari.

But of course, being standards-compliant, it's easy for us to support any browser.

Your numbers will be different, because you're in a different industry with a different customer base.

Re:These aren't the browser stats you're looking f

[Scyber]

Unless you are Google, don't worry about what Google's browser stats are. Instead, look at the browser stats of your OWN web site. Those are your customers.

Well if you have a website that doesn't work well enough in non-IE browsers, most likely those users won't return. Which means that using your own statistics will only reinforce your perception.

Yeah, internet Explorer 7 is still shit.

[Colin Smith]

IE 7 is better, but the support for Cascading Style Sheets is still shite.

We always use fake IE headers in Firefox (3 units)

[Anonymous Coward]

On all three of our computers at this office, (XP, OSX, Linux) we always use fake headers that look like IE just so that some sites will "let us in." Not all features work on "IE only" sites, but we end up blacklisting them from our office use and do not bookmark them for return visits.

Hope this helps. Lots of techies out there would agree that running an "IE only" website just hurts business.

Mod parent up

[Dadoo]

Wouldn't you know, I just lost my mod points. :-(

Check your competitors

[PerfectSmurf]

Do you have any competitors, or are there any companies offering reasonably similar services? Visit their support or forums or Google for complaints that they don't support particular browsers. Also install the various browsers and visit their site(s). Just like features, the more they support the more you probably should. Likewise, if they have big holes in browser support it means something... it could be that you could fill a void for potential clients...

A Modest Proposal

[Sloppy]

If you're even willing to entertain the idea, then why not take it to the next level? Instead of having an interactive ActiveX-heavy website, just have a website that contains one file, a MS Windows-only executable, for your "audience" to download and execute as administrator. Then you won't have to worry about "giving up functionality" at all.

(BTW, you're never going to find the statistics that you want. Having MSIE be in the user-agent header, is practically part of the defacto http standard now. Why? Exactly because of the kind of abuse that you're contemplating. 10 years after the last copy of MSIE has been erased, it will still have 90% marketshare, at least according to the server logs.)

Re:A Modest Proposal

[Anonymous Coward]

Having MSIE be in the user-agent header, is practically part of the defacto http standard now.

Kind of like how almost every user-agent has Mozilla listed in it? I remember reading the discussion on the IE7 blog regarding the use of this and whether or not to drop it.

Re:Count users, not hits. -- you can't

[Wilk4]

The parent post said: "I only count "browsers per known user per day". So users that come in more than once per day are only counted once; anonymous users (and robots/crawlers without a credit card in hand) are excluded."

And *how* do you count users/day accurately? With proxy servers, you *can't* always know that kind of information from server logs, though many logfile analyzer s/w packages will try to make you think you can...

See the Analog logfile analyser docs: What the results mean, and particularly How the web works.
"This section discusses what happens when somebody connects to your web site, and what you can and can't find out about them. If you think that you can get statistics on how many people have visited your web site (or want to know why you can't), then this section is for you."

A Suggestion

[webheaded]

If you've already got some sort of website going, start logging statistics for it. Get a counter of some kind (like the kind at http://extremetracking.com/ and you can look at who goes to your site. As you start to build the real meat and potatoes you will know what your primary audience. I look at these stats all the time for my websites to make sure that my site look good to the majority of my audience.

Engineering VS Development

[Vardyr]

I'm not privy to what exactly "IE-only functionality" is in your case, but perhaps you should rethink your application design if you can't find a way to create a cross-platform solution. With AJAX, Java, and various other technologies with excellent cross-platform support, the only justifications for creating an IE-only site seem to be either DRM systems or laziness. Then again, we could also be dealing with the difference between a developer and an engineer. If you're hitting a point where IE-only functionality is appearing to be a good option, try rethinking what you need the application to do, and how it can do it, from the ground up. You'll probably find a much more future-proof and robust solution without sacrificing end-user functionality. You're right in stating that the audience is what matters, but platform lock-in also requires you to be absolutely certain that your audience doesn't change, the platform you're on won't drastically change, and that you can live with absolutely no assurance of future-proofing by avoiding standards.

Re:Engineering VS Development

[alphamugwump]

AJAX is by no means cross platform. AJAX, for all intents and purposes, is a firefox platform. I can't count how often I get web2.0 sites that are broken with Konqueror, simply because they use firefox JS extensions. Hell, look at the poster child for AJAX, gmail. It doesn't use AJAX for IE, it uses activeX. For firefox, it uses JS. It is just broken with everything else.

Java and flash are better at this sort of thing, but they open up another bag of worms by requiring your users to download plugins.

Re:Engineering VS Development

[Vardyr]

Actually, the reason it uses ActiveX is because the XMLHTTP request is an ActiveX function in IE. Something like this: http://www.w3schools.com/ajax/ajax_browsers.asp sorts through that specific issue. Well-developed AJAX applications are cross-platform and work in IE, Firefox, Opera, and Konqueror. Just because "Web 2.0" site developers don't know how to code properly doesn't mean AJAX isn't cross-platform.

Accurate usage?

[Sciros]

Bowser is bottom-tier, so he doesn't really get used much. Luke (grabfestbowser) is pretty hardcore with him, as are a couple of other folks like Magnum, but for the most part he doesn't see much play.

Makes no sense

[Anonymous Coward]

The question is not "Why code for non-IE" it's "Why not?" The fact of the matter is that if you use open standards (XHTML, XML, CSS, Javascript, XSLT, XPath, or something that will run 3rd-party in all browsers (Java, flash/shockwave *gag*) it will work not only in IE but in all other browsers simply because you are coding to standard. This seems like a no-brainer unless you're microsoft. Also keep in mind that if you code properly with CSS you don't even need to do much more than CSS-hacking in order to make your site work seamlessly with PDAs, phones, 508 (accessibility for people with disabilities), etc. If you can find something that is IE-only (in functionality, not in feature-name like ActiveX) then I'll be surprised but I don't think those things exist. Even ID is using the standard AJAX stuff now instead of their own proprietary one so the reasons to move to IE-only are really dumb.

Like a Mac user would shop at Walmart!

[Anonymous Coward]

lol

E-mail harvestors make a mess of statistics

[Anonymous Coward]

If you ever looked through web site logs, you could probably notice e-mail harvesters (and other junk robots). They identify themselves using a popular OS/browser combination (such as MSIE 6 Windows XP), but you can tell they are robots by their behavior (time between requests, systematic way of browsing links, etc.).

So, do the statistics have a reliable way of telling apart email harvesters? Do the statistics even try?

81%

[mshmgi]

I manage dozens of websites reaching multiple demographics (i.e., business, home users, education, medical, engineering, agri-business, sporting goods). Our sites see roughly 1,000,000 unique visitors each week.

Removing bots out of the stats, on average, I see:

• Windows IE: 81%
• Windows FF: 11%
• Windows NS: 0.1%
• Windows OPERA: 0.1%
• Linux (all browsers): 1%
• Mac OS X (all broswers): 6%

If your site is geared towards highly technical people, expect to see double the FireFox & Linux traffic. If the site is geared towards the average home user, you might only be pissing off 10-12% of your potential customer base by having IE only components. I can't imagine many businesses surviving very long by pisssing off 1 out of every 9 customers ... oh, wait, Microsoft ... forget I said that.

Get some good analytics and tune accordingly

[Selanit]

For a snapshot of the web population at large, check this site:

http://marketshare.hitslink.com/

Their stats are updated regularly, they've got a reasonable level of detail, and lots of pretty graphs.

However, as others have pointed out, you need to be worrying about your particular audience more than anything else. A site like the one I've just given isn't all that useful unless you've got a really huge web site. So here's a three step plan for YOUR web site:

1) At first, design it to work smoothly with as many browsers as you possibly can.

2) Build up a profile on the types of users who visit your site. There are lots of programs that can help you do this. Google Analytics does a decent job, and it's free of charge. Another one is Mint, which some people swear by (it costs $30 USD). There are lots of others out there, of varying quality and abilities. Take your pick.

3) Once you've got a profile built up, tune your web site to suit the abilities of the browsers that most of YOUR particular users favor. You might discover that only 0.002% of your visitors are using Safari, meaning perfect compatibility with Safari is not a major concern for you. Or you might discover that the Opera users of the world swarm your web site like ants swarm spilled sugar, in which case Opera becomes a priority for you.

Lather, rinse, repeat.

Re:These aren't the browser stats you're looking f

[Real_Reddox]

I see your point, but most people use google, no matter what their interests are and if they are advanced users or n00bs.

All the accuracy you'll ever need

[Anonymous Coward]

If reading Accurate Browser statistics has taught me anything it's that Snape kills Dumbledor in Harry Potter. Enjoy Accuracy! I know I do.

Browser demographics

[chord.wav]

Browser demographics are different from site to site. You should make your own statistics. I bet you that /.'s demographics will vary a lot from, say, amazon.com

One Data Point

[localman]

Here's the percentages for the site I work on. I can't reveal specific numbers, but we get many millions of unique visitors per day. As many other posters have mentioned, the answer of what to support greatly depends on who your audience is and what you're trying to achieve. Our audience is over 99% from the US, and represents a more average (read: less tech savvy) cross section of internet users, specifically, those that would buy shoes and apparel online. Your potential customer profile is likely much different, but here's the top 10 browsers/platform combonations we saw last week:

44.93% - Internet Explorer 6.0 Windows XP
26.48% - Internet Explorer 7.0 Windows XP
5.26% - Firefox 2.0 Windows XP
4.90% - Firefox 1.5 Windows XP
3.98% - Internet Explorer 6.0 Windows 2000
2.29% - Safari 419 Macintosh PPC
1.82% - Safari 419 Macintosh Intel
1.39% - Internet Explorer 6.0 Windows 98
0.92% - Safari 312 Macintosh PPC
0.52% - Firefox 1.0 Windows XP

We do our best to support normal operation on all of these platforms (and several others) because at our volume alienating even a fraction of a percent costs real money. And also in our case it's not hard to make things work cross browser because we use simple HTML and minimal javascript.

You ask what you lose by adding some IE only features. The equally important question is what you gain. Are the IE only features you're considering going to increase the value of your application enough to make up for what is lost in potential users? Maybe it is, maybe it isn't. In general I think people overestimate how much fancy features are going to improve usefulness, so be honest with yourself there. Good luck figuring out where to draw the line.

Cheers.

Re:One Data Point

[Anonymous Coward]

I guess this answers the "is linux ready for the desktop" question...

Re:One Data Point

[Johnny Mnemonic]

No Mac FFox, or Mac IE? Hm.

Re:One Data Point

[localman]

That was just the top 10. The whole list is very long :)

FYI, Mac Firefox 1.5 & 2.0 litter the teens under both PPC and Intel. All the prominent Mac Firefox entries combined pull about 1.8%. Mac IE really is dead, coming in at #44 with 0.05%.

The version splits make some things look smaller than they should. The analytics I'm using doesn't allow very fine grained control over improving that. What I'd like would be a way to group by work-alikes. But then that concept may not really hold anyways.

Re:These aren't the browser stats you're looking f

[Bogtha]

Unless you are Google, don't worry about what Google's browser stats are. Instead, look at the browser stats of your OWN web site.

No, this is bad advice too. Walmart's just built a web service that only works in Internet Explorer. How many non-IE users do you think they are seeing in their logs compared with IE users? Looking at your current users can only tell you to keep doing more of the same.

What you need to measure is not what your current visitors use, but what your target audience uses. Unfortunately, the web wasn't built around this kind of need, HTTP is a stateless protocol with unreliable user-agent identification. What you need is good old-fashioned polling. In-band data can be skewed beyond usefulness.

Re:Count users, not hits. -- maybe you can

[Kelson]

Judging by the GP's remark about "robots/crawlers without a credit card," I'm guessing it means they're counting "known users" who have logged into the site. In that case, you can track them pretty accurately, as long as you're willing to ignore traffic from people who have an account, but aren't logged in.

Re:These aren't the browser stats you're looking f

[Anonymous Coward]

Thus retorted the owner of the 10th floor stairs-only accessible wheelchair store out the window to a customer on crutches at ground floor:

"Only abled bodied people buy wheelchairs! What the hell do you want one for?"

And so ignorance becomes truth.

dont know how reliable this is but.....

[Anonymous Coward]

but its got a cross-section of info on browser usage and related

http://www.thecounter.com/stats/

Philosophy is more important than browser share

[carpeweb]

Mod me off-topic if you must, but I think asking about browser share is definitely the wrong place to start. Start by asking why you want a web-based application, and you'll probably confront the fact that "universal client" was at least an important consideration at some point in the evolution (maybe back in the naive days before MS entered the browser market). For every feature you consider, before asking about browser share, think about whether the communication or functionality objective (user can get/do X) requires something so complex or sophisticated that it has to be embedded in a proprietary browser. The vast majority of features don't need the proprietary features, and of those that really, really need them, it might be worth developing multiple options, because "really, really need" usually means revenue$.

Re:These aren't the browser stats you're looking f

[rainman_bc]

Unless you are Google, don't worry about what Google's browser stats are.

Thing is Google probably has the largest sampling available meaning that their numbers will be most accurate about true browser market share.

As another poster pointed out, your web server logs will reinforce the policy your web site's already had, proving nothing to PHB's about enhancing your compatibility.

A good conversation with a PHB would be: Our users on our sites are 99% IE. IE is 80% of the market, therefore in the long run we stand to grow our business by 20% if we start supporting all browsers, and you stand to make 20% more money.

Re:These aren't the browser stats you're looking f

[Tumbleweed]

No, this is bad advice too. Walmart's just built a web service that only works in Internet Explorer. How many non-IE users do you think they are seeing in their logs compared with IE users? Looking at your current users can only tell you to keep doing more of the same.

That's a good point, but I was thinking from the point of view that they hadn't already implemented IE-only stuff.

It IS really annoying that Google doesn't release their browser stats; I don't know what their reasoning is on that one. I'd also like their stats on screen resolution (and window) resolution.

Not to mention that ...

[hummassa]

After one version of a browser passes ACID2, regressions can make it not pass again after a while (konqueror/kde3.5.6 does not pass ACID2 -- at least on my machine)

Re:Not to mention that ...

[great throwdini]

After one version of a browser passes ACID2, regressions can make it not pass again.

While this is certainly true, it doesn't validate ACID2 as a reliable (let alone sole) measure of any browser's competence in handling recommended development guidelines.

Re:Not to mention that ...

[jZnat]

Works for me (3.5.6-0ubuntu6).

Re:These aren't the browser stats you're looking f

[Tumbleweed]

I wonder if Google's stats might be a bit non-IE-centric, though, as IE browsers default to MSN searching, don't they? I guess that might apply to any non-MSN site, though. It would be interesting to base stats on router traffic rather than web sites. Is anyone making that kind of info available for free?

Basic common sense

[Baloo Ursidae]

we got to thinking, exactly how many users would we be alienating by using some IE-only functionality on our website?

I know I might be playing Devil's Advocate here, but if users alienated >0, wouldn't common sense dictate that the move in question is a pretty bad one?

You'll have to find out for your self.

[Zadaz]

As others have said, it's really up to those who visit your site.

If I was deploying a new web application I would start by writing it to standards and making it work with IE and FF out of the box. Then I'd keep track of what browsers hit my main page.

Then I'd make a simple business decision:

if (potentialLostRevenue > costToImplement)
          implement_browser(someBrowser)

Lets say it will take $1500 worth of manpower to implement Opera. If I'm potentially turning away $5K in business from Opera users, I'd implement it. If I'm potentially turning away $200, forget it.

Despite what others have said about Mac users being flush and careless with disposable income, I've found sell-through rates to be roughly the same (within 15%) between OS/browser.

Also, maintenance

[Todd Knarr]

Another thing to think about is future maintenance. Take a look at what IE7 did to IE-only Web sites. Lots of IE-specific things that worked find in IE6 suddenly didn't work or worked badly in IE7 because of changes in the browser. If you'd written an IE-specific Web site that actually used IE-specific features (as opposed to "we only tested it in IE" without using anything beyond bog-standard HTML/CSS/JS), you had headaches. Sites designed to work well in Mozilla, Opera and Safari, by contrast, made the IE6-to-IE7 transition with few if any problems.

So you not only have to ask whether it's worth it to accomodate non-IE browsers, you also have to ask if it's worth it to target only IE and deal with the havoc when Microsoft moves your target again (and they will move it, the only question is when and how far).

what do you need to know....

[zogger]

...besides the fact the millions of people DON'T use IE? Isn't "millions" a large enough number? Now I can see if it was mere thousands, but really, this is 2007, the numbers of people who use anything but IE grows daily and it is a nice fat large number. Yes, it is not as large as IE, but IE is no longer as large a dominating factor as it used to be either and that particular trend is just continuing. If you don't give a crap about those folks-your competition sure will. Ya, it's more work, so what? You potentially want every possible set of eyeballs to hit your site, why tell a section of them to go pound sand? All you will do is save a few bucks now being picky about if it is 10% or 11%, for the fantastic business opportunity of losing business in the future, and alienating potential customers/clients. It is beyond annoying to go to some website and be told you MUST be using such and such a browser, or "go to hell", because that is exactly what you are telling folks, just "go away, we don't like you, we think you are insignificant to us, because you fail to use the most insecure browser ever with features years behind everyone else".

That is not a good way to "win hearts and minds".

There's an old saying that fits, "penny wise, pound foolish". Would a gas station have a color code to get gas "sorry, we don't serve blue or green cars, only red cars".

Ya more work, suck it up. It'll pay off in the future for you.

Re:Count users, not hits. -- maybe you can

[Wilk4]

hmm, perhaps that's what he meant. If so, that's useless for most sites of course.

As I mentioned, many logfile analyzers unfortunately mislead uers into thinking their "user" counts have any validity or mean anything, so he might think he really is counting users.

Re:These aren't the browser stats you're looking f

[Bogtha]

Google used to include some of this information in their Zeitgeist, for example see December 2001. But just because they have representative users, it doesn't mean they can collect representative data from traffic analysis. Browser market share data culled from web statistics is good for entertainment, not for basing important decisions on.

Re:These aren't the browser stats you're looking f

[tverbeek]

But just because they [Google] have representative users

Actually they don't. Their user stats are skewed away from IE users, because IE's default home page (which a surprisingly large number of people leave as their browser's home page) is MSN.com and its default search is Microsoft's; and they're skewed toward Firefox users, which have Google as their default home page and search engine, and slightly skewed toward Safari which uses Apple.com as its default page but Google as its default search engine.

Subjective Editorial Correction

[jshackney]

'[we] don't make that kind of information available for free.'

Well dùhh!

[JamesTRexx]

That's because Firefox has something that IE doesn't have: cool wallpapers! (warning: NSFW!)

Re: Wikipedia Browser Stats

[bunratty]

A wider range of visitors than "people with an interest for web technologies" perhaps?

How about Wikipedia's browser stats? It lists stats from many different sources, not just one web developer oriented site.

My efforts to help out

[bgibby9]

I'm trying to build a complete set of tracking tools and reports for free for anyone to use. By doing this, I also hope to have a better way to output the stats of Browsers and OS'es. It's not perfect but it's growing! http://tracker.buildacomputeronline.com/ I'm going to continue to improve it, but if anyone has any suggestions, I'm all ears.

Think about your developers too

[oyenstikker]

Do your developers use Firefox and heavily utilize features/plugins such as Live HTTP Headers, Firebug, DOM Inspector, and the Javascript Console? Are you going to piss them off by making them work in IE? The cost of having to replace developers and the cost of decreased productivity alone may sway your decision.

What is the point of ACID2?

[hahafaha]

I personally do not understand the whole point of the ACID2 test. It is not valid CSS, so it does not accurately measure how well the site adheres to CSS.

Re:What is the point of ACID2?

[Bogtha]

It is not valid CSS, so it does not accurately measure how well the site adheres to CSS.

What site? Acid2 tests browsers, not sites. As such, it needs to include errors to test whether browsers handle errors correctly. This is not only acceptable, it's actually a requirement to be a proper test. CSS has defined error handling, meaning that the Acid2 test might be invalid code, but it should be parsed in one specific way.

Re:What is the point of ACID2?

[great throwdini]

[ACID2] is not valid CSS, so it does not accurately measure how well the site adheres to CSS.

You need to read the Guided Tour closely, in particular the 'CSS Parsing' bullet within the 'What we are testing?' section.

Re:These aren't the browser stats you're looking f

[tacocat]

It wouldn't be an unreliable user-agent identification if web designers didn't restrict the access of their web sites to specific user-agents in the first place. I see no other reason to spoof who you are other than to get around some artards notion of what browsers can access a page.

It's irrelevent in many cases

[Ankh]

First,you only need one disenfranchised user to sue you. For example, if you are operating a Web site in the US (or in many cases the EU or Canada) anti-discrimination laws mean you'd better make your site accessible. And that means accessible to someone using a text-based browser such as Lynx, as well as a text reader. See the American Disabilities Act and the "508" laws.

Second, yes, you can make a Web site more cheaply that's aimed at, say, IE 6. Or IE 7. or maybe you could choose Mosaic 1.5, or Netscape 0.96, as some other sites did. And in a few years you might have to redo everything when that particular browser is no longer available.

Third, you could optimize your site for a particular screen size. For example, 640x480 pixels or even 800x600 are popular choices. Of course, you can't actually buy a desktop PC with a 640x480 pixel screen very easily today. Mine is 1680x1050, but sizes vary widely, mostly because of the emerging popularity of watching DVDs on a computer. But, right now a surprising number of people in some parts of the world (Europe and Japan mostly I think) seem to browse the Web on a mobile phone, and those often have 320x240 pixel screens.

The point of the World Wide Web is that it's for everyone, everywhere, regardless of language, culture, ability, special needs or even computing platform. Do the right thing. Make your site work on as many platforms as you can, by sticking to standards, avoiding platform-specific tricks, and testing.

[disclaimer: I work for the World Wide Web Consortium, although in this area my opinions expressed here also match those of my empolyer!]

Sticking to standards does not always work on IE

[francium de neobie]

I kept hearing about the "stick to the standards and it will work everywhere!" argument in the replies. But in my experience, this advice only works when you're making simple websites. Try a little bit of good old DHTML or even AJAX and your "sticking to standards" web page breaks down in no time. I would go as far as to claim even things you taken for granted in a sane programming environment would often break down in IE without you noticing what went wrong, I won't prove this claim here, but an example is the memory leak problem in IE6.

First, lets see what's wrong with the "stick to the standards.." argument. If sticking to standards frees you from the troubles of IE, then why isn't the Acid2 test working on IE7? Acid2 sticks to the standards, specifically, it is a test for the CSS standards, and it's not working.

You may say Acid2 uses obscure CSS tags that nobody would use. Then let's try some common DOM alright? Say you want to create a radio button in Javascript via DOM methods. What's the standard way to do that?

var b = document.createElement("input");
b.type = "radio";
b.name = "...";
b.value = "...";
formNode.appendChild(b);

Try this in IE6 (still the dominant browser), the radio button is created, but it doesn't work - you cannot check it by clicking on it. The above code works perfectly in Firefox or Safari. Standard compliance frees you from trouble? My ass!

How, then, can you make a working radio button via Javascript in IE? You HAVE to use non-standard ways. This is how you make a radio button, from MSDN:

var newRadioButton = document.createElement("<INPUT TYPE='RADIO' NAME='RADIOTEST' VALUE='First Choice'>")

See? You cannot simply stick to the standards and expect a working web application.

85% IE, 10% FF, 5% Other

[KermodeBear]

I work for a major internet company that provides portals and premium services to our customers. Their users are 'average joe' types and with about 200,00 unique users on one domain alone I figure that these stats probably hold true for most 'general use' sites.

The breakdown was about 85% IE, 10% FF, and 5% 'Other', which included Safari, Opera (1%), AOL Browser, even some Web TV clients. Over the last few months, IE6 has been shrinking with IE7 gaining and that continues to be the case. Don't expect IE6 to disappear for quite some time, but IE5.5 seems to be dropping into the negligible category - outstripped by FF on most domains.

take a look...

[tulinete]

...to your site statistics and see what kind of users do you have.
but at least make the site compatible with gecko and khtml based browser and ie of course. with this you will keep more than 98% of your visitors.

[OT] which ubuntu????

[hummassa]

mine are the kubuntu-edgy packages at kubuntu.org/packages ... it might be a DPI/font-related problem (the smiley face is larger than the reference rendering and it has a red streak under the second line)

Troll.

[pen]

Really, how much of a troll is this article. You are asking Slashdot about your existing web site's traffic statistics?

Where can one get a current, accurate, and un-biased measurement of browser usage?

In your access_log!

Re:Sticking to standards does not always work on I

[Ankh]

There's a difference between saying, "IE supports every aspect of every standard perfectly" (nothing does, although some programs come a lot closer than others, of course) and saying, "avoid single-browser extensions when possible and use only the portable subset of what is standard". I agree it's not easy though.

Liam

Re: Wikipedia Browser Stats

[zobier]

How about Wikipedia's browser stats? How about Wikipedia's own browser stats? I'd like to see that.