@csnover: Thanks for the in-depth write-up on this, it's appreciated. As to the particular bug that you link to I would definitely need to see a test case for what that one is trying to describe - I've never seen a bug like that before (especially one across platforms as it describes) and I'm skeptical that it is as described.



To go into the browsers that you mention, in particular:



Firefox 2: It's not really costing us anything to continue maintaining it. I don't think we have any Firefox 2-specific code in our library at this time.



Safari 3: Unfortunately Safari is going to haunt us forever. We dropped Safari 2 support a while back but there's a chance that we might need to bring support for that back in if we want to handle Symbian S60v3 (a very popular mobile platform that uses a Safari 2-esque browser). It should go without saying that the Safari 3 browsers are everywhere in mobile and we're not dropping support for them any time soon.



Opera 9: (Specifically Opera 9.6) Not really costing us anything to continue maintaining it. Although mobile haunts us here as well. Opera Mobile is rather popular and we should be trying to increase our Opera browser coverage. Ideally we'd be going back to the Opera 8.x series - but that's some rough territory.



Chrome 4: This is one browser that would probably be good to drop. It's really really hard to test against multiple versions of Chrome - since there isn't any way to install them side-by-side. I would probably be content to only support 'Chrome' (the latest release). This is definitely an exception from other browsers in that the userbase upgrades so quickly. Note that I would separate out Android Mobile from this browser and support that explicitly and for a longer amount of time.



It's really important to realize that there's a rather large mis-conception regarding browser coverage: That having an increased coverage yields a significantly larger file size. This is definitely not the case - for most of the browsers outlined here (save for Safari 2) we have little to no browser/feature-specific workarounds in our code to handle them. The only time in which we can really start to talk about reductions in file size is when we only support browsers that have both querySelectorAll and matchesSelector - and that's probably never going to happen.



To outline, again, what it means to have support for a browser: If a bug comes up for a browser that we support we will prioritize it and try to fix it accordingly. Even browsers that we don't support will get bug fixes (namely to stop browser crashes and the like). Additionally before the release of the code we make sure the test suite passes in all the browsers that we support. This generally takes about a day to do, regardless of the number of browsers that we support - so keeping a few on is hardly a major concern.

