So, are you suggesting that jQuery should break compat all the way back to 1.0? Or should we try John for heresy?

Replying to [comment:1 rwaldron]:

So, are you suggesting that jQuery should break compat all the way back to 1.0? Or should we try John for heresy?

Of course not. While some have called me mad, I've yet to be titled lunatic.

All I'm proposing is to ''add'' the option to pass the ''dataType'' before the success callback. Since ''dataType'' is always a string and the success callback is always, well, a function (and risking the Dunning–Kruger effect), this should be pretty easy to implement.

Replying to [ticket:10209 joe@…]:

John Resig has highlighted the importance of API consistency numerous times. As an example, he says that jQuery is set up to ALWAYS take the callback function as the last parameter. However, $.get & $.post can both get a "dataType" parameter after the callback (all the way back to jQuery 1.0). Although this is not practically a bug (since this is intentional) it is against the API consistency theory.

Here's my proposed fix:

 // allow for callback to be passed in as last argument
if ( jQuery.isFunction(type) ) {
   var tempType = callback;
   callback = type;
   type = tempType;
}

As long as your content-type headers are correct in the server's response, jQuery will handle the dataType for you, which means you wouldn't need to define that param anyway...

Replying to [comment:4 rwaldron]:

As long as you're content-type headers are correct in the server's response, jQuery will handle the dataType for you, which means you wouldn't need to define that param anyway...

I don't understand what you're trying to say. jQuery ''does'' support incorrect content-type headers (by setting the dataTpe), and the API should be consistent with the rest of jQuery.

Are you proposing to get rid of the dataType argument altogether?

certainly not... I just think this is a completely unnecessary change.

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

Replying to [comment:7 trac-o-bot]:

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

I truly believe that this should be addressed, since it's such an easy fix.

I've done all the work, and modified the above solution to take into account all possible scenarios ([url, data, dataType, success], [url, dataType, success] & [url, non-primitive dataType, success]).

I created a fiddle with the code, as well as a test for all variations possible (also showing that there's no regression):

http://jsfiddle.net/afC5g/1/