[mkmcdonald]

I'll play the cynic here and try to diagnose why this is even being considered.

jQuery is a very invasive API. Its goal is to steal all the work from the developer, and to "guarantee" what it deems to be "correct" input for a certain subset of browsers. This approach may ostensibly work, but inevitably falls apart, which leads to thousands of "bugs" being reported.

Because the API has grown to be so massive, goalposts "must" be moved in order to create a lighter API. Once again, this is because of a design flaw. Goalposts will continue to be moved in cyclical fashion unless an alternative design is used. Fellow developers may denigrate me for it, but I will explain how this problem can be avoided.

An API that tries to cater to everyone cannot and will not succeed. This is evidenced by the upcoming "fork". Conversely, an API that provides a set of tools to developers without catering can work in many environments. The burden is then placed upon the developer to choose which environments matter. As has been outlined by mobile developers, object inferences for IE 6 really are unnecessary for mobile Webkit environments. I have written here on this concept before, mostly on the topic of "graceful degradation". Browser specificity can and will kill a client-side API.

[secoif]

I don't know what your definition of software success is if jquery doesn't fall in that category.

[tianshuo]

jQuery is throwing its burden --- on developers and users. But since it is on 1/3 of websites, maybe it does have the power to influence a change.