jQuery 1.9.1 Released

31 thoughts on “jQuery 1.9.1 Released”

1. mitchell zhu on February 5, 2013 at 1:32 am said:

   i don’t need migrate plugin and i just need $.browser,because many many plugin use $.browser
   please please please support $.browser~~~~just $.browser~~ thank you
2. Skoua on February 5, 2013 at 6:01 am said:

   Thanks!

   I must agree with mitchell that a separate file to support $.browser only which is used by some plugins would be great.
3. River on February 5, 2013 at 6:54 am said:

   $.browser is a bad practice jQuery moved away from. Plugin authors should switch to more reliable feature detection instead of relying on browser sniffs.

   I’m sure someone will throw $.browser into a plugin, but you should probably avoid it for future code, almost everything can be feature tested. http://modernizr.com
4. Adeel on February 5, 2013 at 7:05 am said:

   I’ve extracted the $.browser code into a separate file in case someone else needs it:
   https://gist.github.com/adeelejaz/4714079
5. Lee on February 5, 2013 at 7:37 am said:

   Please please please add $.browser back, not only is it used to detect features (which can be replaced by moderniser or $.support), it’s also used in some cases where people only need to know browser version.

   For example:
   if ($.browser.msie) {
   $(”).html(‘Out website does not support Internet Explorer, please use Chrome instead.’).appendTo($(document.body));
   }
6. Stifu on February 5, 2013 at 8:04 am said:

   @Lee: your example still sounds like something that could be replaced with feature sniffing. Your website does not support IE because IE does not support certain things, right? So your logic should be “browser needs features A, B and C”, not “browser should not be this particular browser brand”.
7. Anahkiasen on February 5, 2013 at 9:07 am said:

   As mentioned above, you people should try something like Modernizr and detect actual features instead of plain blocking (which is bad and you should feel bad) of specific browsers.
8. noname on February 5, 2013 at 9:08 am said:

   @Adeel: thanks! I just needed the $.browser to know which effin’ browser and version was visiting my website :)
9. Christian on February 5, 2013 at 3:24 pm said:

   “$.browser is a bad practice jQuery moved away from. Plugin authors should switch to more reliable feature detection instead of relying on browser sniffs.”

   I’ve explained elsewhere that feature detection does NOT always cut it. On a project I am working on now I need “$.browser” to handle a Firefox bug that cannot be sussed out with feature detection. See http://stackoverflow.com/questions/14105890/jhtmlarea-adding-unwanted-br-tag for some info on just one such problem. Once I figured out this was a Firefox-only problem I had to use “$.browser” to account for the unwanted BR tag in Firefox only.

   It is rare, fine-grained instances like this where “$.browser” is still needed. In saying this I am not recommending that “$.browser” be used to “sniff” for a certain browser at the beginning of page load and then serve totally separate large chunks of JavaScript/jQuery to different browsers as back in the old days of browser sniffing (“Here’s one enormous set of JavaScript for Internet Explorer and one for Netscape.”).

   Please consider re-including “$.browser.” Hopefully people can grasp what I’m saying here rather than tuning out what I’ve said and thinking that I and others are trying to “block” certain browsers or some other such bad scenario.
10. Johannes on February 5, 2013 at 3:51 pm said:

    @Christian, See the link Adeel provided above.
11. Christian on February 5, 2013 at 7:10 pm said:

    I saw it. I am giving a reason for its inclusion in jQuery itself, emphasizing that this feature is something other than just a poor replacement for feature detecting.
12. galin on February 6, 2013 at 3:09 am said:

    $.browser is still needed for some cases.
    so reinclude it in future versions of jQuery.
13. Martijn on February 6, 2013 at 4:25 am said:

    Personally I don’t see the point in saving <1KB (minified) in a 91KB framework (the 33KB specified is false; just checked it) by removing features that are going to cause backward compatibility issues.
14. Stifu on February 6, 2013 at 8:25 am said:

    @Martijn: it’s not just about size, but also maintenance (among other likes, like consistency, best practices, etc). Keeping old features is not “free”. If the jQuery team wants to reorganize or rethink their code (and they keep doing it), then having fewer things to worry about speeds things up.
15. dmethvin on February 6, 2013 at 8:27 am said:

    And as always, you are welcome to put browser detection back via jQuery Migrate, using the older version, the gist from Adeel above, checking navigator.userAgent directly, etc.
16. honeyryderchuck on February 6, 2013 at 10:55 am said:

    ahaha, very funny to see all the rollover over $.browser not being supported. I don’t understand all the fuss because: it’s an extensible framework, so you can just rewrite, overwrite or move features to subplugins (and use Adele’s link); jQuery is quite old in internet years and quite fat, does some things very well, some things so-so and some things which other frameworks are better at (like the already cited Modernizr), so it’s actually a wise decision to lose that fat; if you are using plugins relying on $.browser, then it probably means you are using the wrong plugin for the job developed by someone who’s either not developing it actively anymore, doesn’t pay attention to deprecation warnings or doesn’t update himself on framework changes.

    jQuery handles the document and provides a very simple API for XHR requests; it is not very good at browser sniffing and browser feature detection, or for basic element feature enhancing (underscore.js). jQuery needs to be trimmed because it’s not 2007 anymore and there are other libraries that are accomplishing many tasks jQuery doesn’t need to.
17. Christian on February 6, 2013 at 3:14 pm said:

    “if you are using plugins relying on $.browser, then it probably means you are using the wrong plugin for the job developed by someone who’s either not developing it actively anymore, doesn’t pay attention to deprecation warnings or doesn’t update himself on framework changes.”

    But it doesn’t necessarily mean that. My reason for mentioning that they should still include it is based on theirs and others’ false belief that $.browser is 100% equal to “feature detecting.”
18. SeaGull on February 7, 2013 at 10:42 pm said:

    Please, return $.browser back.
    It’s the only part of “jquery-migrate” all my projects need.
19. Rodrigo Rosenfeld Rosas on February 8, 2013 at 7:03 am said:

    I’d guess most people here complaining about $.browser being removed would be happy with just booleans like $.IE, $.IE6, $.IE7, $.IE8, $.IE9 :D Or simply $.IE(version) where all versions would return true if version is not passed in… :)
20. Joshua Tenner on February 8, 2013 at 8:33 am said:

    Thanks for the updates! I won’t complain about the $.browser removal.

    I needed an excuse to learn how to use modernizr.
21. aikeru on February 9, 2013 at 2:12 pm said:

    Thank you for continuing to trim the fat on this awesome JavaScript library! Please don’t add ‘browser’ back. There are many options to get it back and it IS a poor way to do what most people use it for. I HATE it when a website “doesn’t support my browser” when my browser may work just fine.
22. KOnnark on February 11, 2013 at 10:45 am said:

    Why it’s not available on Google CDN?

    I don’t understand the jQuery’s homepage: at the top there is “Download jQuery 1.9.1” and at the bottom you see “Download jQuery 1.9.0″…
    If they can’t even be consistent/coherent on their own homepage, I can’t imagine what it actually is in the jQuery lib itself!!!
23. FeedFixer on February 13, 2013 at 6:11 am said:

    FYI The RSS feed for the jQuery blog appears to be broken. It just loads the blog default page rather than an RSS/XML file.
24. qlwik on February 14, 2013 at 8:12 am said:

    Thanks for update, think again about adding $.browser :P
25. Peter Mouland on February 17, 2013 at 8:49 am said:

    “$.browser”

    Some versions of chrome that have the transitionend event it is unreliably implemented i.e. it didn’t always fire after the css transition had finished.

    With so many new features making their way into browsers (along with a couple of bugs) like the above example, i am not sure how you would feature detect this inadequacies.

    To detect the bug found by @Christian might also be similar and unreliable or will involve triggering events and possibly replicating human behaviour to find the bug. Is this overkill (and hit website performance) if the browser and version number are known?
26. thedavidmeister on February 18, 2013 at 6:13 pm said:

    Please put $.browser back in. Regardless of whether it’s “bad practise” to use it or not as an end user, API breaks across minor versions of a library is far worse “bad practise”!
27. Christian on February 20, 2013 at 9:37 pm said:

    I *just* had to include the following in the same project I mentioned above):

    if ($.browser.mozilla) {
    $(‘.jHtmlArea IFRAME’).attr(‘onload’, ‘this.contentWindow.focus()’);
    }

    This was because an element was not getting focus in Firefox on page load when it was in other browsers. I don’t know a way to feature detect for whether or not a form element will get focus in every browser except Firefox. But even if there is a way the point here is that I am not doing a “browser sniff” before any other JavaScript is loaded and then serving a couple thousand unique lines of JavaScript/jQuery to Firefox and not to other browsers and then serving different sets of unique code to those other browsers. I am doing a “browser detect” and serving *one line* of reparative code to Firefox. This is one example of the need to retain “$.browser.” Additionally, the plugin this line of code relates to has to itself detect if the browser is IE or Safari (note: *not* “webkit”) and do the following quick maneuvers:

    increaseFontSize: function () {
    if ($.browser.msie) {
    this.ec(“fontSize”, false, this.qc(“fontSize”) + 1);
    } else if ($.browser.safari) {
    this.getRange().surroundContents($(this.iframe[0].contentWindow.document.createElement(“span”)).css(“font-size”, “larger”)[0]);
    } else {
    this.ec(“increaseFontSize”, false, “big”);
    }
    }
28. Gabriel Cebrian on February 26, 2013 at 12:59 am said:

    Here is a jQuery plugin that will bring $.browser back. https://github.com/gabceb/jquery-browser-plugin
29. Ilia on March 8, 2013 at 9:48 am said:

    I have no problem with removal of $.browser but the reality is that browser sniffing is sometimes necessary. This is especially true for mobile development where feature detection is often just not enough. (check out Smashing Mag’s The Mobile Book if you don’t believe me.)

    In any case, for those needing $.browser functionality check out http://conditionizr.com/
    Conditionizr works like Modernizr but for browser detection, and even more. It will also detect retina-like displays, touch events and even OS version. On top of that it has built in (but optional) functionality of loading scripts (e.g. html5 shim) or CSS (e.g. ie7.css) based on what you detected. So it’s really like a better version of $.browser plugin. (Note, I’m in no way associated with Conditionizr, I just started using it recently and find it extremely helpful.)
30. Douglas on March 11, 2013 at 5:37 am said:

    i can’t tell you how impressed i am with the work you guyz have done for the community! It takes a lot to write something so robust and yet give it away for free! Hands down you guys are the best may God bless you more!
31. Nat Darke on March 25, 2013 at 12:11 pm said:

    @ people complaining about $.browser being removed. There is a version of jQuery available that supports all your needs. It is called jQuery 1.8. You will love it. Or write your own library and give it away for free….oh, I thought not.