Also in: jQuery UI

jQuery Licensing Changes

Posted on September 10, 2012 by Dave Methvin

Some important changes have occurred in the latest releases of several jQuery projects such as core, UI, Mobile, Sizzle, and QUnit. You may not have noticed them because they didn’t really change the actual code, documentation, or functionality. Instead, these changes were designed to clarify the ownership and licensing of the software. If you’re not a lawyer, most of this won’t make a lot of difference to you, but it’s important to us.

One simplification we made was to remove the GNU General Public License (GPL), leaving only the MIT License. Having just one license option makes things easier for the Foundation to manage and eliminates confusion that existed about the Foundation’s previous dual-licensing policy. However, this doesn’t affect your ability to use any of the Foundation’s projects. You are still free to take a jQuery Foundation project, make changes, and re-license it under the GPL if your situation makes that desirable. The Free Software Foundation site confirms that the MIT License is a “lax, permissive non-copyleft free software license, compatible with the GNU GPL.”

Over time, more than 500 people have contributed to the projects currently managed by the jQuery Foundation. We’re working hard to make sure that everyone who has contributed gets the credit they deserve. Many of the projects now have an AUTHORS.txt file in their root that list all the major contributors in chronological order. Scott González did a lot of the heavy lifting to get the author lists in order, and created useful tools so that we can keep them that way. Of course, you can always see the author of a specific change to a project by looking at the commit in the git log or on GitHub.

It’s important to the jQuery Foundation that licensing of the code and documentation is clear, so the community can continue to use it without interruption. Doing so requires a “paper trail” so it is unambiguous that the Foundation has permission to use the code and the contributor had the ability to contribute that code in the first place. For an example of the latter, think about the situation where an employee works on jQuery Foundation projects at the company office; their employer might claim they own that work and the employee had no right to license it to the Foundation.

To make the licensing clear, contributors are asked to sign a Contributor License Agreement (CLA). jQuery team members will sign a Copyright Assignment Agreement (CAA) which actually assigns the copyright to the jQuery Foundation. For more discussion of what a CLA or CAA does, see this article.

All of these changes guarantee that the jQuery Foundation’s open source projects will be dependable resources for developers and businesses. They also ensure that when you contribute, you’ll get some recognition for the work that you’ve done. So with all that legal stuff out of the way, come help us build the jQuery Foundation projects!

jQuery 1.8 Released

Posted on August 9, 2012 by Dave Methvin

August just got a little hotter, because jQuery 1.8 final code is here! You can pick up the code from jQuery’s CDN:

http://code.jquery.com/jquery-1.8.0.min.js (compressed and minified, for production)
http://code.jquery.com/jquery-1.8.0.js (uncompressed, for debugging)

As usual, the Google and Microsoft CDNs will also have the file soon. Please don’t ask us about when they’ll be there, we don’t know and we don’t control those CDNs! Use our copies directly from the jQuery CDN above if you’re just itching to get started. It’s the same bits.

We don’t expect to get any bug reports on this release, since there have been several betas and a release candidate that everyone has had plenty of opportunities to thoroughly test. Ha ha, that joke never gets old. We know that far too many of you wait for a final release before even trying it with your code. So now there is really no reason to wait, and you can find out if there are any bugs you could have reported earlier.

If you do find a bug, please create a test case on jsFiddle or jsbin and file a bug on our bug tracker. If you’re not sure whether you’ve found a bug, ask on our forum. jQuery core 1.8.0 is compatible with the latest versions of jQuery UI (1.8.22), and jQuery Mobile (1.1.1). Be sure to update those if you’re reporting bugs on pages that involve them.

A Whirlwind Tour of jQuery 1.8

Let’s just recap the big changes in this release:

Sizzle re-architected: jQuery’s selector engine is faster than ever, thanks to a rewrite (well, really two rewrites) by Timmy Willison. Sure, most browsers have querySelectorAll nowadays, but nearly every implementation falls short in one way or another, creating a road full of cross-browser potholes. Sizzle smoothes that road for you. Plus, you may want those useful jQuery selector extensions like :has() with a complex selector or :contains(). Oh yeah, and there’s still IE6/7 support.

Animations re-imagined: Over time, the animation code in jQuery had become kind of messy. Corey Frang took a head-first dive into that swamp and managed to remove most of the alligators, um, bugs. Most of the changes are under the covers, so existing animations should just work (and work better). But there are also some awesome additions to make animations more general and extendable. One notable and very cool feature is the use of the progress callbacks in Promises. We’re still working on detailed documentation, but we do have a draft. Also, here’s an example of the new code in action: http://jsbin.com/odocid/1/edit.

Automatic CSS prefixing: When you use a CSS property, in either .css() or .animate(), we’ll use the correct prefixed property (when appropriate) for that browser. For example, take .css("user-select", "none"); in Chrome/Safari we’ll set the value as "-webkit-user-select", Firefox will use "-moz-user-select", and IE10 will use "-ms-user-select".

More flexibility with $(html, props): In jQuery 1.8, you can use any jQuery method or plugin in the object passed to $(html, props). Before, you could only use a short list of method names, and there was no documented way to add to the list. Now there doesn’t need to be a list at all! Be aware, however, that this can cause the behavior of your code to change if plugins are added later that have the same names as HTML attributes.

More than 160 bugs closed: The Sizzle and animation rewrites in particular provided the impetus to fix several long-standing bugs–some of which have been around for two or three years. Mike Sherov tackled most of the open CSS and positioning issues, getting us down to near-zero bugs there. We also haven’t given up and are still pounding away to eliminate annoying differences between IE 6/7/8 and modern browsers, so you don’t have to deal with them.

Smaller code size: Despite all the code cleanup, new features, and bug fixes, the gzipped file size of jQuery 1.8 is actually a few hundred bytes smaller than jQuery 1.7.2. Size reduction wasn’t our primary goal in this version, but we felt it was important to hold the line on code growth, and we definitely achieved that. Many thanks to Richard Gibson for leading the code-crunching charge across the entire project.

Modularity: If you know your project’s jQuery dependencies well, you can use the new grunt-based build system to strip out parts of jQuery that you know you don’t need. What we’ve done here for 1.8 is really just a beginning, you’ll see even more flexibility as we move to later versions.

The full changelog is available below, in case you’re wondering whether your favorite bug was squashed.

What’s Been Removed

The short answer is “very little”. We wanted to provide a generous notice period for deprecated features that will be removed in 1.9, to give people time to adapt their code. Several of the things removed in 1.8 were undocumented internals that some people have cleverly reverse engineered, but it’s always risky to use undocumented features. Here are the items removed:

$(element).data(“events”): In version 1.6, jQuery separated its internal data from the user’s data to prevent name collisions. However, some people were using the internal undocumented “events” data structure so we made it possible to still retrieve that via .data(). This is now removed in 1.8, but you can still get to the events data for debugging purposes via $._data(element, "events"). Note that this is not a supported public interface; the actual data structures may change incompatibly from version to version.

Deferred.isResolved() and Deferred.isRejected(): Calling N-1 boolean methods to get the state of an N-state variable was getting a bit silly, so we added Deferred.state() in jQuery 1.7 to tell you the state in a single call. So, these two older methods aren’t needed anymore. It’s much more convenient for debugging scenarios where you often want to know the state of a Deferred as a string.

$(element).closest(Array) returning Array: This was a strange signature of the .closest() method intended for use by the old .live(), but not used by any other code as far as we know. Normal uses of .closest() returning a jQuery object are not affected by this signature being removed.

$.curCSS: This method was simply an alias for jQuery.css() from jQuery 1.3 onward. Although it has never been part of the documented API, some external code has been known to use it, perhaps thinking it was “more efficient.” Now it’s “more gone.”

$.attrFn: Yet another undocumented item, used to define which methods could be used in conjunction with $(html, props) signature. Although it serves no functional purpose in jQuery 1.8, we are leaving an empty $.attrFn in jQuery to prevent code that uses it from throwing errors. Fair Warning: This will be removed entirely in jQuery 1.9, so update your code!

Where Credit’s Due

This release couldn’t have happened without the hard work of the talented jQuery Core team: Julian Aubourg (jaubourg), Corey Frang (gnarf), Richard Gibson (gibson042), Mike Sherov (mikesherov), Rick Waldron (rwaldron), and Timmy Willison (timmywil).

Special recognition goes to these jQuery team and community members who supported the Core team with patch contributions during the jQuery 1.8 development cycle: Andy Monat, Robert Katic, Joaoh Bruni, Sindre Sorhus, Oleg Gaidarenko, Yehuda Katz, Timo Tijhof, Dominik D. Geyer, Scott González, Jörn Zaefferer, Matt Farmer, Trey Hunner, Jason Moon, Ben Alman, Jeffery To, Kris Borchers, Daniel Herman, Vladimir Zhuravlev, Jacob Thornton, Chad Killingsworth, Nowres Rafid, David Benjamin, Uri Gilad, Chris Faulkner, Elijah Manor, and Daniel Chatfield.

We’re also very thankful to those of you who took the time to report bugs; we can’t possibly fix a bug unless we know it exists. If you’re looking for an easy way to contribute to jQuery, get to know the bug tracker and help us by creating reduced test cases that clearly demonstrate bugs. Once we can reproduce a problem, a solution usually isn’t too far away. Those test cases become the foundation for a unit test that can prevent the problem from happening when we change code in later revisions.

jQuery 1.8 Change Log

Ajax

#8205: JSONP random result is causing memory leak in IE8
#8653: jQuery.param outputs "null" and "undefined" in the query string
#9399: Deprecate jqXHR.success and jqXHR.error
#10285: evalScript rcleanScript replacement fails in IE8
#10524: jQuery.fn.load does not merge data parameter with jQuery.ajaxSetup
#10944: $.ajax does not always return an object implementing the Promise interface
#11013: Deprecate use of Deferred/Promise with sync $.ajax
#11402: evalScript function fails with error error 80020101 in IE
#11743: jQuery silently ignores errors during script tag ajax request in $.appendTo()
#11778: Cached XHR requests should still resolve asynchronously
#12122: jQuery.ajax() async deprecate use with $.Deferred

Attributes

#11153: jQuery 1.7 Strips Carriage Returns in IE 8
#11212: Sizzle.getText converts unbreakable space into whitespace on IE
#11547: XML DOM .removeAttr() doesn't remove cased attributes
#11962: Standardize getter return values for empty sets.
#12127: Clone does not correctly copy checked state in IE10

Build

#11767: Support custom build without effects
#11789: Update README to describe grunt build system
#11856: modularize dimensions
#11857: modularize css
#11865: modularize offset
#11965: Create deprecated.js to contain as much of the deprecated stuff as possible
#12059: `grunt custom` should minify – also should add excluded modules to headers
#12158: jQuery 1.8rc1 does not work with YUICompressor 1.4.7

Core

#10657: Deprecate jQuery#size() in favor of jQuery#length
#11290: selector interpreted as HTML
#11470: Adding a builtin readyP promise
#12018: $(document).ready() fires too early in IE8
#12026: Let $(html, props) use any jQuery.fn method

Css

#10373: `document.defaultView` => `window`
#10394: jQuery.cssHooks.opacity throws exception on non-IE browsers
#10413: width, innerWidth, innerHeight, outerWidth, outerHeight are inaccurate for a "box-sizing: border-box" child of hidden parent
#10679: CSS3 vendor prefix support
#11004: getWH incorrectly removes padding and border width when box-sizing is border-box
#11787: Remove jQuery.curCSS
#12088: Webkit now returning percentages for more getComputedStyle properties
#12148: hide event don't fire when toggle

Data

#7579: jQuery.data() truncates numbers taken from data-xxx attributes
#10589: Remove $.fn.data("events")
#11435: Obsolete test code to remove toJSON from .data's return value

Deferred

#11010: Make Deferred.then == Deferred.pipe like Promise/A
#11011: Allow traditional options object for $.Callbacks flags
#11736: Remove Deferred .isResolved() and .isRejected()
#11749: Preserve context objects when multiple Deferred object are passed to $.when()

Dimensions

#6724: wrong $(window).height() in mobile safari (iphone)
#10877: Make outerWidth/Height a setter
#11293: Reading width or outerWidth of empty TDs alters columns width values
#11604: Switch $(elem).width(-val) from no-op to $(elem).width(0)
#11724: $(document).height() changed in Firefox 12

Effects

#7109: animate width starts with invalid width on webkit
#7157: Animation callback shows element is still ":animated"
#8387: flickering problem with jQuery 1.5 hide/show issue with inline and inline-block elements on webkit browsers
#8627: .animate() fails on letterSpacing in IE (regression in 1.5.1)
#8892: Callback is raised before objects are shown with fadeIn() and jQuery.fx.off = true
#9217: javascript error in IE8 when animating element is removed before animation finishes
#9505: animate() issue when mixing percentages and pixels in WebKit
#11635: Explicit overflow:auto is overridden by inline overflow:hidden during animation
#11755: animate and it aliases should not use :hidden selector
#11797: New animation related events
#11854: percentage animations jump to end
#11971: Animating background-position fails in IE8
#11999: Incremental animation on fixed div does subtraction instead of addition in Chrome.
#12117: overflow hidden not properly set when animating to 0 height or width
#12138: fadeOut doesn't work in Chrome on basic SVG elements
#12150: border-spacing property accumulates when rows are shown and hidden

Event

#8545: Leak with events in IE
#10067: Firing $.ready on document.readyState === 'interactive' too
#10895: The doScrollCheck ie hack in bindReady degrades ie7 performance for no reason whatsoever
#11101: Deprecate "exclusive" events option from trigger method
#11315: Problems with delegate() and :first in nested elements with equivalent classes
#11328: Ctrl key doesn't set event.metaKey to true on Windows
#11382: Mouseenter doesn't fire on a disabled input element
#11500: Bug : "change" event handler not executed when triggered manually on IE7 & IE8
#11621: Triggering a event on document doesn't bubble to window
#11718: Deprecate .data() events
#11719: Deprecate .bind("ready") event
#11731: Deprecate "hover" pseudo-event
#11733: Deprecate .load(), .unload(), and .error() methods
#11764: Allow delegated non-native events on disabled elements
#11786: Deprecate .toggle( handler, handler, … ) signature
#12203: .undelegate() with no arguments unbinds all handlers from the parent element

Manipulation

#8894: appendTo() and alike methods called after clone() returns incorrect jQuery set in IE
#10324: Clone does not copy innerHTML of object element in IE9
#11231: Append, Prepend, After, Before should accept an array as first argument
#11325: Improve domManip/buildFragment/clean
#11338: Inconsistent behavior with .replaceWith() and disconnected nodes.
#11528: ie8 serialization bug with .html() also hitting html5 tags
#11566: node.append et al. does not work when node is a DocumentFragment
#11617: Define a $.parseHTML method for creating HTML fragments
#11809: Memory leak in .text(val) setter?
#11898: prevAll() with a complicated :not() selector returns results in wrong order
#12132: IE10 bug when cloning an object element without a parentNode

Offset

#10996: Simplify offset()
#11823: Remove webkitConvertPointFromNodeToPage

Selector

#3778: selector matching issues
#5568: Selectors behave differently with comments tags on FF/IE
#7596: xpath selector attribute name with brackets [] fails
#8473: In IE9rc *[tabIndex] select all elements without tabindex also
#8906: .(prevAll('span:has(input,select,textarea)')
#9400: Deprecate :text, :radio, :checkbox, etc. selector extensions
#9810: Rewrite Positional Selector Logic
#10003: Regression/BC break from #6963
#10074: Chaining two [] selector with :first not working
#10499: :nth-child() inside :has() treated as if outside it
#10570: :text selector throws an error in IE7 when there is a cross domain iframe on the page
#10697: Sizzle revamp
#10799: Inconsistent results with [name="name"] selectors (also breaks .has)
#10809: incorrect test using ".activeElement" in the :focus pseudo-class resolver
#11109: Sizzle: Expr.relative truncates prematurely
#11120: Tabs in some selectors break in IE7
#11814: Sizzle's element-rooted QSA strategy (i.e. attaching a temporary id) does not account for comma and other other selector divisions
#11826: Explore a parsed caching system for matchesSelector within Sizzle
#11902: :not + :contains selectors
#11918: :eq selector problem when using tag name with ':'
#11959: Add support for :active selector
#11961: "Maximum call stack size exceeded" when using jQuery#is
#11966: descendant selector
#11969: Missing null check when gathering siblings
#12054: Uncaught TypeError: Object #<HTMLDocument> has no method 'getAttribute'
#12057: Sizzle Regression
#12082: .find() POS selector no longer working in 1.8b2
#12153: Error occurs in the selector

Support

#9385: Deprecate jQuery.browser
#11163: jQuery.support.checkClone always true
#11249: CSP error in Chrome 18 when loading jQuery 1.7.1
#11439: jQuery.support.parentNode used, but not defined any more.
#11721: deprecate and remove internal uses of jQuery.support.boxModel
#11757: IE 8 memory accumulation in iframes with jQuery 1.7.2
#11766: Move jQuery.support to "unstable" status

Traversing

#9800: New method: .addBack (supersedes .andSelf)
#11539: All version of jQuery don't support .has() on $([text Element].parentNode).has?(other_element)
#11543: .has doesn't work on detached elements
#11706: `.has()` fails on document fragments
#11738: Remove .closest(Array) returning Array

The New Sizzle

Posted on July 4, 2012 by Timmy Willison

In order to make your 4th of July more sizzlin’ (you’re welcome), the jQuery team is happy to announce that Sizzle, jQuery’s CSS selector engine, is better, faster, and more reliable than ever! Sizzle has received a substantial rewrite to be included with the release of jQuery 1.8.

First, credit should be given to Diego Perini for pointing me in the right direction as well as Samuel Lebeau for creating a project 3 years ago called Bouncer, a “fast bottom-up element matcher for Javascript”.

jQuery, along with Sizzle, was released in 2006, about 3 years after Simon Willison came out with getElementsBySelector, which pretty much set the stage for every selector engine we have today. As time went on, Sizzle was rewritten a few times for the sake of performance and more and more bugs were covered as the number of people using it increased.

During this time, other quite impressive selector engines were introduced, including but not limited to NWMatcher (by Diego), dojo.query, Slick, base2, qwery, and YUI. Though they all have their own strengths, NWMatcher and Dojo particularly stood out as exemplary engines. While neither is the fastest at every selection, they are both consistently fast for almost every selector. My goal was to achieve this same level of performance for Sizzle, retain all of the edge-case bug fixes that John and the bugs team have collected over the years, and cover even more bugs that were in the queue or were covered by other engines. I can now safely say this goal has been reached.

While I won’t say Sizzle is completely bug free or it is always the fastest in every situation, the reliability and performance gains are very competitive. http://jsfiddle.net/timmywil/s7rN4/ is a primitive test used to quickly observe the differences between some selector engines for several selectors (should be run in a browser with a console open).

What changed

Below is a reduced list of the main code differences between Sizzle in jQuery 1.7.2 and jQuery 1.8.

One compiled selector function

The selector parser compiles a selector into one function containing functions for each part of the selector. This means that for any given selector (excluding positional (POS) selectors such as :first or :eq(3)), the possible set of elements need only be checked once. This is predominantly where the major speed boost and heightened stability comes from.

Additionally, Sizzle maintains a cache of the most recently compiled functions. The cache has a maximum size (which can be adjusted but has a default) so you don’t get out-of-memory errors when using a lot of different selectors.

Note: this does not have an effect on simple selectors (ID-only, TAG-only, CLASS-only) because Sizzle has had shortcuts for these that defer to getElementByID, getElementsByTagName, and getElementsByClassName whenever possible. That wasn’t changed (except for the addition of a shortcut for element-rooted ID selectors), and those are still the fastest selectors. Any other selector will go through querySelectorAll if available or run through the compiler.

`querySelectorAll` and `matchesSelector`

With this latest rewrite, the code paths to querySelectorAll and matchesSelector are even better than before and yield excellent performance.

Some people ask why we need Sizzle at all, since modern browsers have querySelectorAll and matchesSelector and accept a wide range of CSS3 selectors. The problem is that every browser (not just IE) has a few bugs in these methods. Selector engines must know beforehand what these bugs are and bypass these methods before they return incorrect results (though not all of them do). Sizzle now has this covered.

In addition, querySelectorAll and matchesSelector do not know how to process jQuery selector extensions such as [attr!=value]. Any time you use a selector extension, Sizzle needs to handle the selection natively.

Improved selector validation

Validating selectors is a tricky business. To be too strict can be annoying, but to be too flexible can produce unexpected results. In the past, Sizzle has been both of these at different times for several use cases. The most recent changes are geared towards adhering to the W3C selectors specification as much as possible, but also allowing some things that the spec does not (such as having complex selectors within a :not() pseudo).

Specifically, we are matching all whitespace characters where necessary, including line feed, tab, carriage return, and form feed(http://www.w3.org/TR/selectors/#whitespace), validating identifiers and operators in attributes selectors (http://www.w3.org/TR/selectors/#attribute-selectors), and providing a character encoding that matches the spec (http://www.w3.org/TR/css3-syntax/#characters).

Combinators (space, ~, >, +)

Combinators can get very complicated, but the new strategy handles these with great poise. In the release of jQuery 1.8 beta (and at the jQuery conference this year), I claimed that Sizzle had improved support for combinators. While the accuracy was improved, I spoke too soon and, fortunately, this was pointed out by someone I only know as Yaffle on github. Apparently, for very large and deep documents, the original revisions were checking so many elements that it was causing a stack overflow for selectors that had several combinators. For each combinator, the number of elements checked went up exponentially in order to maintain possible matches. This was bad. Sizzle now takes care of that issue and gets very satisfying results.

Extensibility

Although most of the old API for Sizzle was not changed in this rewrite (except for the removal of the now unnecessary Sizzle.filter from the private API), there are a couple changes that make Sizzle even more extensible. The most common way to extend Sizzle is to add custom pseudo selectors. Now with the parser compiling a function of functions, you can receive more information when creating your custom selector. For example, within Sizzle, the implementation for the :not pseudo selector is very similar to

// Using the createPseudo function tells the compiler
//   to pass the pseudo argument, context, and whether the current context is xml
//   to the function passed to createPseudo and trusts
//   that a function to be used for filtering will be returned.
// Note: the use of createPseudo is only necessary for creating custom
//   pseudo selectors with arguments.
Sizzle.selectors.pseudos.not =
    Sizzle.selectors.createPseudo(function( selector, context, isXml ) {
        var matcher = Sizzle.compile( selector, context, isXml );
	return function( elem ) {
		return !matcher( elem );
	};
    });

This is the only breaking change in the public API given the new parser, but I think creating custom pseudos with arguments is now much cleaner. For more information, please refer to the Sizzle docs.

Perhaps some of you are thinking that it could be nice to pre-compile your own selectors. Well, you can. Sizzle.compile is exposed so you can cache your selectors before they get used. While compiling is still very fast without caching, you can make sure that step is skipped before the selection is ever run. Call compile with your selector and context

Sizzle.compile(“my>long>complicated:selector(poof)”, document);

and it’s added to the cache. You can even increase/decrease the size of the cache by setting Sizzle.selectors.cacheLength.

Note: The majority of users do not need to use the compiler as Sizzle will maintain a cache of recently compiled selectors. Overriding Sizzle.compile will have no effect on Sizzle as it maintains an internal reference to this method.

Get the code!

The code is now available in the git versions of jQuery and Sizzle. Expect jQuery 1.8 to be released sometime this month. Issues specifically for Sizzle can be filed on GitHub and, as always, any issues related to jQuery as a whole can be filed on our bug tracker. Try it out for yourself and let us know if you run into any problems. Enjoy and Happy Independence Day!

jQuery 1.9 and 2.0 — TL;DR Edition

Posted on July 1, 2012 by Dave Methvin

It seems that many people had questions and misconceptions about the last post, so let’s try a short Q&A format to answer some of the comments left there.

Why is the jQuery core team dropping support for oldIE (IE 6/7/8)? We’re not! jQuery 1.9 will support oldIE when it’s released next year. The jQuery team will continue to support and maintain version 1.9 even after jQuery 2.0 is released.

Why are you making me use conditional comments to include jQuery? We’re not! You can use jQuery 1.9 for all the browsers we support, from IE6 all the way up to the latest versions of Chrome, Safari, Opera, or Internet Explorer.

What happens when jQuery 2.1 is released and adds APIs, will jQuery 1.9 support them? Can we borrow your crystal ball? jQuery 2.1 isn’t likely to arrive until 2014, so it’s hard to say what jQuery 2.1 will look like as we sit here in the middle of 2012. Our general goal is to keep the 1.x and 2.x lines in sync and add functionality via plugins; see the keynote from last week’s conference.

How long will you support jQuery 1.9? As long as oldIE is a significant factor on the web. It’s even possible that there will be further releases in the 1.x line, but we haven’t yet received the crystal ball requested in the previous question. When Microsoft drops Windows XP support in April 2014, however, it will put a hurt on the oldIE installed base.

I still have a lot of IE8 users, can’t you just drop IE6 and IE7? The oldIE browsers share many of the same flaws, so it doesn’t help to do anything less than remove all three in jQuery 2.0. If you need oldIE support of any kind, a supported jQuery 1.9 will be right there for you.

My website is in China and 22 percent of our users are still using IE6! Seems like some sort of human rights violation. Oh, and that wasn’t a question.

jQuery Core: Version 1.9 and Beyond

Posted on June 28, 2012 by Dave Methvin

Please check out the followup post before jumping to the wrong conclusion.

As the last blog post discussed, jQuery version 1.8 is undergoing a spring cleaning to remove insecure, inefficient, ineffective, and inadvisable features. We’ve also begun the work to allow you to build custom versions that exclude parts of the library for even greater savings. Those efforts will make it possible for you to enjoy the jQuery API you need without carrying around the parts you don’t want.

Now that we’ve cleaned house, it’s time to take a look forward. There’s just one thing interfering with our vision of the future, and that’s the ghost of browsers past. Internet Explorer 6, 7, and 8–collectively, oldIE–have been a thorn in the side of web developers for a decade. Collectively, these browsers of a bygone era still represent up to one-third of users visiting some sites. That is a lot of users–people who still want the information, services and products that web sites provide. For many web sites that use jQuery, it’s not practical or profitable to ignore that audience.

jQuery was conceived specifically to address the differences in browsers, so we’re not going to abandon the essence of our philosophy and simply disregard the millions of active Internet users who (for whatever reasons) still use oldIE. Yet we also want to move ahead and take advantage of modern browsers, especially the growing mobile market.

The Road Ahead

jQuery 1.8 should arrive within a month. Here is our thinking about the next two versions of jQuery to follow it, and when they’ll arrive:

jQuery 1.9 (early 2013): We’ll remove many of the interfaces already deprecated in version 1.8; some of them will be available as plugins or alternative APIs supported by the jQuery project. IE 6/7/8 will be supported as today.
jQuery 1.9.x (ongoing in 2013 and beyond): This version will continue to get fixes for any regressions, new browser bugs, etc.
jQuery 2.0 (early 2013, not long after 1.9): This version will support the same APIs as jQuery 1.9 does, but removes support for IE 6/7/8 oddities such as borked event model, IE7 “attroperties”, HTML5 shims, etc.

Our goal is for 1.9 and 2.0 to be interchangeable as far as the API set they support. When 2.0 comes out, your decision on which version to choose should be as simple as this: If you need IE 6/7/8 support, choose 1.9; otherwise you can use either 1.9 or 2.0.

Questions and Answers

If jQuery 1.9 and 2.0 are basically the same API, what makes 2.0 compelling? Smaller size, better performance, and the lack of problems introduced by the need for oldIE support. We expect that we can improve error handling in the $.Deferred implementation in 2.0, for example, whereas we can’t do that as long as oldIE is supported.

My site still has many IE7/8 visitors but I want to use jQuery 2.0. Can I do that? If your web site needs oldIE support, and we expect most sites will need it for at least another year or two, you can use IE conditional comments to include version 1.9 only when visitors are using oldIE:

<!--[if lt IE 9]>
    <script src="jquery-1.9.0.js"></script>
<![endif]-->
<!--[if gte IE 9]><!-->
    <script src="jquery-2.0.0.js"></script>
<!--<![endif]-->

Why not make an “oldIE plugin” for jQuery 2.0? Special dispensations for oldIE are sprinkled throughout jQuery. Refactoring the code to provide enough hooks so that oldIE support could be added as a plugin would complicate the code for the modern browser case. Plus, developers supporting oldIE and using a public CDN would then need to include two files (jQuery 2.0 and the oldIE plugin) instead of one.

Once jQuery 2.0 is released, what happens to 1.9? In a departure from the past, we’ll continue to fix bugs in 1.9 (as minor releases). Having just gone through a spring cleaning for 1.8 and 1.9, we don’t anticipate adding a lot of new APIs in the future. Instead, we prefer to add new functionality through plugins compatible with both versions where it makes sense. So don’t feel like you’re being left behind when using version 1.9.

Is jQuery 2.0 basically for mobile devices? No. Although jQuery 2.0 will be a great fit for HTML mobile apps, including ones written with jQuery Mobile, it is not a Webkit-only library that targets just iOS and Android. In addition to mobile browsers, 2.0 will support (and be tested!) with modern desktop versions of Internet Explorer, Opera, Firefox, Safari, and Chrome.

How much smaller/faster will jQuery 2.0 be? We won’t know until we’re done, or at least close to being done. You can bet that we’ll tell you more as the release date for 2.0 draws near. Better yet, you can try the beta when it is released and see for yourself!

jQuery 1.8 Beta 1: See What’s Coming (and Going!)

Posted on June 22, 2012 by Dave Methvin

Hello fellow jQuery users! It’s been a while since you’ve heard from us, but we haven’t been asleep. The jQuery Core Team has been heads-down working on jQuery 1.8, and our first beta release is now available! You can get the code from the jQuery CDN:

http://code.jquery.com/jquery-1.8b1.js

Give it a try on your current jQuery code and let us know how it works for you. If you experience issues, please file a bug, include a test case, and be sure to mention that you’re testing against jQuery 1.8 Beta 1.

There will be even more exciting jQuery news at the jQuery Conference in San Francisco later this month, with blog posts to follow.

jQuery is now powering about one-half of all the major web sites on the Internet; that’s a great success, but we’re not standing still. Web browsers and the devices they run on have undergone an incredible metamorphosis in the past six years. The process of web development is evolving to accommodate the changes that are happening. In response, jQuery continues to evolve as well.

Part of that evolution is not just knowing what to add, but what to take away. jQuery’s plugin architecture makes it easy for developers to extend the functionality that jQuery Core offers when it makes sense for their own needs. For that reason, the bar has been set pretty high for additions to Core. We don’t want to create size, complexity, or performance penalties for people who don’t need specific features.

Similarly, we have enough experience with the way that people use jQuery to know some features that originally seemed like a good idea turned out to be a not-so-good idea. Rather than carry these around forever, we want to remove them eventually. In fact, we want to make it easier to create a version of jQuery that excludes things you don’t need or want, especially for mobile environments where space can be precious.

With that in mind, here are some changes we are planning for jQuery 1.8 that will make it a better foundation for all HTML-based web pages and applications, regardless of their platform:

Modularity

As of jQuery 1.8, you can build a custom version of jQuery that excludes one or more modules if you do not need their functionality. This capability is made easy by our new build system based on Ben Alman’s awesome grunt tool. To build your own custom version, set up a copy of the jQuery core repo from Github and use the grunt command line options to exclude modules. For more information, see the README file.

The modules you can currently exclude are ajax, css, dimensions, effects, and offset. For example, if your application exclusively uses stylesheets and CSS animations via classes to control the visibility and size of items on the page, you could build a version without the css, dimensions, effects, and offset modules. If you didn’t need any of the optional modules, your custom build of jQuery would be about 21KB minified and gzipped.

Don’t worry though, building your own jQuery is completely optional. jQuery has always been, and will continue to be, distributed as a single file in both compressed and uncompressed form and available on CDNs. We still expect that to be the way most jQuery developers go, because it’s simple and painless. For example, when you include a jQuery plugin that you didn’t write, using the full jQuery ensures you won’t be bitten by some dependency lurking inside the plugin.

Vendor-Prefixed CSS Properties

The W3C had its heart in the right place when it came up with the idea to use vendor prefixes for CSS features that were not yet standardized, but it hasn’t resulted in a fairy-tale ending. Web developers are faced with the nightmare of including all the vendor-prefixed property names in stylesheets. jQuery 1.8 eases the pain a bit. We automatically take the non-prefixed property name and generate the prefix that is appropriate for the current browser, so you don’t have to. For example, on Chrome the jQuery call $("#myscroll").css("marquee-direction", "backwards") will set the CSS to -webkit-marquee-direction: backwards.

Animation (Effects)

Our code for animation had become a tangled mess over the past few years, and with 1.8 we hope we’ve brought the beast under control. It’s more than just a cleanup, though; there are several extension points that make it easier to add or modify animations. At the moment there is only preliminary documentation for the new features, but in this first beta our primary focus will be on ensuring that any existing animation code works properly.

Browsers are doing a much better job providing efficient animations today, particularly with CSS transitions. Yet there are still plenty of users who don’t have a browser capable of doing CSS-based animations. With jQuery 1.8 you get the best of both worlds. If you need to support older browsers without built-in animations, the new $.Animation provides a solid foundation and fixes many bugs from previous versions. If you need to target only modern browsers and their natively supported animations, you can do that and exclude the animation module entirely.

Sizzle CSS Selector Engine

jQuery’s selector engine has undergone a major rewrite in 1.8. The most notable benefit of this rewrite is a widespread performance improvement of selector matching as well as improved shortcuts for the most common selectors.

Additionally, Sizzle handles many more edge cases and bugs, including improved support for multiple combinators (~ > +) and better detection of browser bugs in querySelectorAll. See the bugs list below in the selector module for a complete list.

XSS Protection

By design, the $() method can create HTML elements, and will run scripts if it is passed a <script> tag with inline script or a src attribute. Developers have sometimes forgotten this, passing strings to jQuery that come from untrusted sources such as the URL or user input. In these cases, it is possible for someone to inject a script into the page that can steal cookies or compromise the page in some way.

These cross-site-scripting (XSS) attacks are common on many sites whether they use jQuery or not, but we want to ensure jQuery does not contribute to the problem. In jQuery 1.9 (the NEXT version following 1.8), we’re tightening down the “looks like HTML” rule for the $() method. A string will only be considered HTML if the first character is a less-than sign, otherwise it will be assumed to be a CSS selector.

As further protection against the inadvertent injection of scripts, jQuery 1.8 introduces a new method: $.parseHTML. It lets you specify strings as HTML and know that they will be parsed as HTML, something that $() cannot do since it also interprets strings as selectors. It also provides a way to parse HTML into a DOM fragment and control the execution of any scripts the HTML it may contain. This is particularly important in JavaScript environments controlled by Content Security Policy (CSP), since injected scripts may cause security warnings or exceptions.

For anything more than the simple case of creating single elements (e.g., $("<p/>")), and particularly for cases where strings are built from external data, we strongly recommend using $.parseHTML. As of jQuery 1.9, some HTML strings will no longer be recognized by $() as a result of these stricter rules.

Spring Cleaning

In jQuery 1.8 we’ll also be deprecating and removing “trip hazards”: APIs and features that are inefficient, ineffective or inadvisable. We realize that there will be existing jQuery code that still requires these features. To provide a low-hassle future upgrade path, we’ll be providing many of the deprecated items in a compatibility plugin after they are removed. You can follow the compatibility plugin as it is developed on its GitHub repo.

Tickets below that begin with “Deprecate” or “Remove” tell the whole story of what is changed, but here are a few changes of particular note:

$.browser: Ever since jQuery 1.4, we’ve been evangelizing that browser detection via the user agent string is a bad idea. Yet we’ve been an enabler of bad practice by continuing to offer $.browser. As of jQuery 1.9 we’ll remove it entirely and you’ll need to use the 1.9 compat plugin. If your code isn’t weaned off browser detection yet, check out Modernizr for a very thorough set of feature detections you can use instead. And of course, you’re welcome to read the tea leaves in the navigator.userAgent string directly, there’s nothing stopping you but your conscience.

$.sub: This method was introduced in jQuery 1.5, but hasn’t proved to be useful or robust enough to justify it staying in core. It will move to a compatibility plugin in jQuery 1.9.

Global ajax events: Events such as ajaxStart fired by $.ajax can currently be attached to any element–even to elements that are not in a document at all! This creates an inefficient special case, so we are deprecating that behavior in 1.8. Ajax events should be attached only on document as of 1.9.

And Much Much More…

There are many other changes in 1.8, perhaps the easiest way to see what we’ve been up to is to look at the list of issues that are being fixed, which includes both features and bug fixes. Here is a snapshot of 1.8 as it stands today, but it’s not set in stone. We welcome your feedback about specific issues or the direction of jQuery in general!

jQuery 1.8 Beta 1 Change Log

The current change log of the 1.8 Beta 1 release.

Ajax

#8205: JSONP random result is causing memory leak in IE8
#8653: jQuery.param outputs "null" and "undefined" in the query string
#10285: evalScript rcleanScript replacement fails in IE8
#10524: jQuery.fn.load does not merge data parameter with jQuery.ajaxSetup
#10944: $.ajax does not always return an object implementing the Promise interface
#11013: Deprecate/remove async option from $.ajax
#11402: evalScript function fails with error error 80020101 in IE
#11743: jQuery silently ignores errors during script tag ajax request in $.appendTo()
#11778: Cached XHR requests should still resolve asynchronously

Attributes

#11153: jQuery 1.7 Strips Carriage Returns in IE 8
#11212: Sizzle.getText converts unbreakable space into whitespace on IE

Build

#11767: Support custom build without effects
#11789: Update README to describe grunt build system
#11856: modularize dimensions
#11857: modularize css
#11865: modularize offset

Core

#10657: Deprecate/remove jQuery#size() in favor of jQuery#length
#11290: selector interpreted as HTML
#11470: Adding a builtin readyP promise

Css

#10373: `document.defaultView` => `window`
#10413: width, innerWidth, innerHeight, outerWidth, outerHeight are inaccurate for a "box-sizing: border-box" child of hidden parent
#10679: CSS3 vendor prefix support
#11004: getWH incorrectly removes padding and border width when box-sizing is border-box
#11787: Remove jQuery.curCSS

Data

#10589: Remove $.fn.data("events")

Deferred

#11010: Make Deferred.then == Deferred.pipe like Promise/A
#11011: Allow traditional options object for $.Callbacks flags
#11736: Remove Deferred .isResolved() and .isRejected()
#11749: Preserve context objects when multiple Deferred object are passed to $.when()

Dimensions

#6724: wrong $(window).height() in mobile safari (iphone)
#10877: Make outerWidth/Height a setter
#11293: Reading width or outerWidth of empty TDs alters columns width values
#11604: Switch $(elem).width(-val) from no-op to $(elem).width(0)
#11724: $(document).height() changed in Firefox 12

Effects

#7109: animate width starts with invalid width on webkit
#7157: Animation callback shows element is still ":animated"
#8387: flickering problem with jQuery 1.5 hide/show issue with inline and inline-block elements on webkit browsers
#8627: .animate() fails on letterSpacing in IE (regression in 1.5.1)
#8892: Callback is raised before objects are shown with fadeIn() and jQuery.fx.off = true
#9505: animate() issue when mixing percentages and pixels in WebKit
#11635: Explicit overflow:auto is overridden by inline overflow:hidden during animation
#11755: animate and it aliases should not use :hidden selector
#11854: percentage animations jump to end

Event

#8545: Leak with events in IE
#10067: Firing $.ready on document.readyState === 'interactive' too
#11101: Deprecate "exclusive" events option from trigger method
#11328: Ctrl key doesn't set event.metaKey to true on Windows
#11500: Bug : "change" event handler not executed when triggered manually on IE7 & IE8
#11621: Triggering a event on document doesn't bubble to window
#11718: Deprecate .data() events
#11719: Deprecate .bind("ready") event
#11731: Deprecate "hover" pseudo-event
#11733: Deprecate .load(), .unload(), and .error() methods
#11786: Deprecate .toggle( handler, handler, … ) signature

Manipulation

#8894: appendTo() and alike methods called after clone() returns incorrect jQuery set in IE
#10324: Clone does not copy innerHTML of object element in IE9
#11231: Append, Prepend, After, Before should accept an array as first argument
#11338: Inconsistent behavior with .replaceWith() and disconnected nodes.
#11566: node.append et al. does not work when node is a DocumentFragment
#11617: Define a $.parseHTML method for creating HTML fragments

Offset

#10996: Simplify offset()
#11823: Remove webkitConvertPointFromNodeToPage

Selector

#3778: selector matching issues
#5568: Selectors behave differently with comments tags on FF/IE
#8473: In IE9rc *[tabIndex] select all elements without tabindex also
#9400: Deprecate :text, :radio, :checkbox, etc. selector extensions
#10003: Regression/BC break from #6963
#10074: Chaining two [] selector with :first not working
#10570: :text selector throws an error in IE7 when there is a cross domain iframe on the page
#10697: Sizzle revamp
#10809: incorrect test using ".activeElement" in the :focus pseudo-class resolver
#11109: Sizzle: Expr.relative truncates prematurely
#11814: Sizzle's element-rooted QSA strategy (i.e. attaching a temporary id) does not account for comma and other other selector divisions
#11826: Explore a parsed caching system for matchesSelector within Sizzle

Support

#9385: Deprecate jQuery.browser
#11439: jQuery.support.parentNode used, but not defined any more.
#11721: deprecate and remove internal uses of jQuery.support.boxModel
#11766: Move jQuery.support to "unstable" status

Traversing

#9800: New method: .addBack (supersedes .andSelf)
#11543: .has doesn't work on detached elements
#11706: `.has()` fails on document fragments
#11738: Remove .closest(Array) returning Array

Unfiled

#11325: Improve domManip/buildFragment/clean
#11435: Obsolete test code to remove toJSON from .data's return value
#11777: Add jQuery Core support for EditorConfig file

jQuery 1.7.1 RC1 Released

Posted on November 17, 2011 by Dave Methvin

Just to let you know we’re not asleep at the switch around jQuery Central, we’ve got a new preview release of jQuery. It fixes the problems reported by the community since the original 1.7 release. Please test the code in your applications, making sure that there are no major problems. If you tried jQuery 1.7 and reported a bug, it should be fixed in this release.

You can get the code from the jQuery CDN:

You can help us by dropping that code into your existing application and letting us know that if anything no longer works. Please file a bug and be sure to mention that you’re testing against jQuery 1.7.1 RC1.

We want to encourage everyone from the community to try and get involved in contributing back to jQuery core. We’ve set up a full page of information dedicated towards becoming more involved with the team. The team is here and ready to help you help us!

jQuery 1.7.1 RC1 Change Log

The current change log of the 1.7.1 RC1 release.

Ajax

#10723: jqXHR.always() returns a Promise instead of a jqXHR object

Attributes

#10724: $(document).text() always returns an empty string
#10773: removeAttr is fragile for edge cases

Build

#10630: Fix focus-related test failures to resolve Swarm failures

Core

#10616: Type coersion not done for -1 in .eq
#10646: Have jQuery.error throw instanceof Error object
#10682: Creating DOM elements with $(‘ ‘) leaks memory and skips the fragment cache
#10687: jQuery calls the AMD define() global function too early
#10690: isNumeric

Css

#10733: remove uses of jQuery.each in css module in favor of a for loop

Data

#10675: Use internalKey shortcut instead of jQuery.expando

Effects

#10669: .animate() no longer animates percentage(%) width
#10750: A “null” in the data object can cause an error in stop

Event

#10676: wheelDelta not added to mousewheel event anymore
#10701: Problems with submit forms using submit function
#10704: special.handle method should fire under origType name
#10705: off bug event name parser
#10712: Triggering blur with live bind broken
#10717: A triggered load bubbles up to window
#10791: Delegated Events fail on SVG elements
#10794: .triggerHandler should not .preventDefault()
#10798: live(“submit”) and .submit() would cause unobtrusive ajax live to fire twice

Manipulation

#10177: index of callback function in .wrap is always 0
#10667: HTML5 Support in .wrapAll() does add a “:” to element
#10670: rnoshimcache probably not constructed correctly
#10812: passing empty object to .before() or .after() throws exception in IE7

Misc

#10691: remove all occurrences of the “equals” and “same” function in the unit tests`

Support

#10629: IE is much too sensitive concerning the fake body. Explore cleaning up support.js to avoid any future crashes

Building a Slimmer jQuery

Posted on November 8, 2011 by Dave Methvin

jQuery is more than five years old now! Over that time it has evolved along with the browsers, web sites, devices, developers, and users that it serves. It has also, um, grown quite a bit over that time. jQuery has added a lot of useful features, but it’s also accumulated cruft that we’d prefer not to support into perpetuity. It may not be an issue on a desktop PC with a high-speed connection, but we want jQuery to be a good solution for mobile devices as well.

Along with our continuing push for higher performance, our priority for upcoming versions is a smaller gzipped file size. It’s hard to do that when every new feature or bug fix must also preserve all existing features and behavior. So today, we want to start a conversation about slimming down the jQuery API by deprecating some features. Here are our guidelines for deprecation:

We don’t believe the feature represents current best practice in the use of jQuery.
The feature has proven unpopular, confusing, inefficient, or ineffective in actual use.
It is not practical or feasible to enhance the feature or address its limitations.
Removing it at some future time could yield notable usability, size, or performance benefits.

Deprecation is just the first step in a process that you can participate in. It is our goal to:

Explain the reasons for deprecating a particular feature, as described above.
Give at least one major-point-version, and often more, between deprecation and removal.
Provide alternatives to deprecated features so that migration is not painful.
Listen to community feedback regarding deprecation and removal.

Occasionally, as in the situation with event.layerX/layerY in version 1.7, we will make a breaking change with shorter notice if we judge that it will cause less pain to remove the feature immediately than to leave it in. Those will hopefully be rare exceptions.

Version 1.7 Deprecations

With those things in mind, we consider the following features to be deprecated as of version 1.7. Existing code that uses them continues to work, but the recommended alternatives are a better choice for compatibility with future versions.

.live() and .die(): We continue to get many bug reports and see user confusion regarding the quirks of the .live() method. Common issues are now documented on its updated API page. We strongly advise the use of .on() or .delegate() for new code, since they are better APIs. Given its widespread use it’s unlikely we will remove this API in 1.8, but please do update your code as soon as possible.

Non-standard event properties: As part of our push to improve event handler performance, we are also deprecating the copying of several event properties from the native event object to the jQuery event object and will remove them in 1.8: attrChange, attrName, relatedNode, and srcElement. Instead of accessing these through event.NAME you can access them via event.originalEvent.NAME where needed.

$.ajax() Deferred aliases: In version 1.5 we defined .error()/,success()/.complete() on the jqXHR object as aliases for the Deferred’s .fail()/.done()/.always() methods. Although that seemed like a good idea at the time, it makes jqXHR a non-standard Deferred. That’s not good. Whenever possible, use the deferred/promise method name in preference to the jqXHR one. We still have some work to do here to provide a full migration path, so we are likely to continue supporting the aliases past 1.8.

deferred.isResolved() and deferred.isRejected(): Now that Deferreds and Promises have progress notifications and a convenient .state() method, we are deprecating these older methods and will remove them in 1.8. Getting the state of an N-state object using N-1 Boolean methods is a cruel-code version of “Twenty Questions”. Deferred-based code rarely needs to inspect state, and the string returned now is more convenient for a debugging scenario where it’s often used.

.attr(“value”) on inputs: For backwards compatibility, we’ve been returning the current value here (as in “what is currently in the input box”) versus the real attribute (what the value attribute says in the HTML). That leaves us no way to provide the true attribute value, and is confusing since W3C selectors work on the attribute and not the current value. So we are deprecating this behavior and will remove it in 1.8. Always use the .val() method to get the current live value of an input element. Until we can reclaim the attribute, you can use $("selector")[0].getAttribute("value") except on IE 6/7 where that will still return the current value. (Our 1.8 solution will get the attribute value on all browsers and is another reason why we’re anxious to change this.)

.closest(Array) returning Array: This signature is a bit of a strange bird, it was created for use by the old live events code but it returns an Array rather than a jQuery object. As of 1.8 we plan to remove it. The other signatures of .closest() are here to stay and are not affected.

.data(“events”): jQuery stores its event-related data in a data object named (wait for it) events on each element. This is an internal data structure so in 1.8 this will be removed from the user data name space so it won’t conflict with items of the same name. jQuery’s event data can still be accessed via jQuery._data(element, "events") but be aware that this is an internal data structure that is undocumented and should not be modified.

$.sub() as a plugin: Although $.sub() can be useful for creating interference-free zones for plugins, it is not used by jQuery core and not widely used by other code, so we intend to transition it to a plugin in version 1.8 to save space.

Looking Towards jQuery 1.8

Given our push for a svelte jQuery, the filter for new features in 1.8 will be stringent. Even performance-related proposals need to be balanced against the space they use or save. Features that can be implemented via plugins, special events, attribute hooks, or other jQuery extension mechanisms are likely to stay outside core for now.

That brings up the question of what we could deprecate in 1.8 and eventually remove to simplify and streamline the library. Those things don’t have to totally disappear; they could move into a separate plugin, for example, and only be included when needed. Take a look at how you use jQuery, and talk about it with your colleagues.

Within a few weeks, we’ll be opening the call for your ideas concerning jQuery 1.8 with another blog post — so start thinking about it now!

Edit: No, we’re not removing IE6 support yet, and we can’t. As John Resig mentions at every jQuery Conference, most of the sins of IE6 are also visited upon IE7 and IE8, which together still have more than one-third of desktop browser market share. It doesn’t make sense to remove support for IE6 until we can whack IE7 and IE8 as well.

jQuery 1.7 Released

Posted on November 3, 2011 by Dave Methvin

jQuery 1.7 is ready for download! You can get the code from the jQuery CDN:

This new release should also be available on the Google and Microsoft CDNs within a day or two.

Thanks to your help in testing and reporting bugs during the beta period, we believe we have a solid, stable release. If you do find problems, file a bug and be sure to choose jQuery 1.7 in the version selection. Also be sure to provide a jsFiddle test case so we can quickly analyze the problem.

What’s New in jQuery 1.7

The Version 1.7 tag at the API site is a great way to get up to speed with the new things in this release. Here’s a rundown of the big items in 1.7 and some things not yet mentioned in the API docs.

New Event APIs: .on() and .off()

The new .on() and .off() APIs unify all the ways of attaching events to a document in jQuery — and they’re shorter to type!

$(elements).on( events [, selector] [, data] , handler );
$(elements).off( [ events ] [, selector] [, handler] );

When a selector is provided, .on() is similar to .delegate() in that it attaches a delegated event handler, filtered by the selector. When the selector is omitted or null the call is like .bind(). There is one ambiguous case: If the data argument is a string, you must provide either a selector string or null so that the data isn’t mistaken as a selector. Pass an object for data and you’ll never have to worry about special cases.

All the existing event binding methods (and their corresponding unbinding methods) are still there in 1.7, but we recommend that you use .on() for any new jQuery project where you know version 1.7 or higher is in use. Here are some examples of mapping between the old and new API calls:

$('a').bind('click', myHandler);
$('a').on('click', myHandler);

$('form').bind('submit', { val: 42 }, fn);
$('form').on('submit', { val: 42 }, fn);

$(window).unbind('scroll.myPlugin');
$(window).off('scroll.myPlugin');

$('.comment').delegate('a.add', 'click', addNew);
$('.comment').on('click', 'a.add', addNew);

$('.dialog').undelegate('a', 'click.myDlg');
$('.dialog').off('click.myDlg', 'a');

$('a').live('click', fn);
$(document).on('click', 'a', fn);

$('a').die('click');
$(document).off('click', 'a');

Improved Performance on Delegated Events

Event delegation has become increasingly important as size and complexity of pages grow. Application frameworks such as Backbone, JavaScriptMVC, and Sproutcore make heavy use of event delegation. With that in mind, jQuery 1.7 event handling was refactored with an eye to making delegated events much faster, especially for the most common cases.

To optimize the code for the most commonly used forms of selectors, we examined a cross-section of code from Google Codesearch. Nearly two-thirds of the selectors used in .live() and .delegate() method calls were in the form tag#id.class where one or more of tag, id, or class were used. By parsing those simple selectors in JavaScript at the time the event was attached, we were able to outperform even the browser’s native-code implementations of matchesSelector during event delivery. For more complex selectors we still use the Sizzle engine, so all existing code should continue to work.

The final result is that delegated events are delivered in about half the time they took in 1.6.4:

Better Support for HTML5 in IE6/7/8

Anyone who has tried to use the new HTML5 tags such as <section> has no doubt run across the problem that IE 6/7/8 not only don’t understand these tags, they actually remove them from the document. With jQuery 1.7 we built in support for using HTML5 tags in older IEs with methods like .html(). This support is on par with what previously required innerShiv. You must still include html5shiv (or Modernizr) in the head of your document in older IEs for HTML5 tag support. For more background, see The Story of the HTML5 Shiv.

Toggling Animations Work Intuitively

In previous versions of jQuery, toggling animations such as .slideToggle() or .fadeToggle() would not work properly when animations were stacked on each other and a previous animation was terminated with .stop(). This has been fixed in 1.7 so that the animation system remembers the elements’ initial values and resets them in the case where a toggled animation is terminated prematurely.

Asynchronous Module Definition (AMD)

jQuery now supports the AMD API. Note that jQuery 1.7 is not a script loader itself; it cooperates with AMD-compliant loaders such as RequireJS or curl.js so it can be loaded dynamically and the ready event can be controlled by the loader. Now an AMD-compliant loader can load an unmodified version of jQuery 1.7 from a CDN such as Google’s or Microsoft’s. Many thanks to James Burke (@jrburke) for submitting the patch and unit tests, then waiting patiently for us to incorporate it.

jQuery.Deferred

The jQuery.Deferred object has been extended with new progress handlers and notification methods that call those handlers. This allows you to asynchronously notify listeners of progress in a request without resolving or rejecting the request. In addition, there is a new state() method that returns the current state of the Deferred; it’s primarily useful for debugging.

Deferreds are now implemented using a new jQuery.Callbacks feature, a generalized way of queueing and triggering a series of handlers. This feature may be of interest to plugin writers, although Deferreds and the event subsystem provide a higher-level interface for this type of functionality.

jQuery.isNumeric()

Inside jQuery we’ve found several situations where we need to know if an argument is numeric, or would be successfully converted to a number if it is some other type. We decided to write and document jQuery.isNumeric() since it’s a useful utility. Pass it an argument of any type and it returns true or false as appropriate.

Removed Features

event.layerX and event.layerY: We have removed these non-standard properties in version 1.7. Although we normally would have gone through a deprecation notice period for these, Chrome version 16 generates a flood of console warning messages on the page. Because of this, we decided to remove them immediately. On platforms that still support these properties, they are available through event.originalEvent.layerX and event.originalEvent.layerY.

jQuery.isNaN(): This undocumented utility function has been removed. It was confusing because it appropriated the name of a built-in JavaScript function but did not have the same semantics. The new jQuery.isNumeric() serves a similar purpose, but has the benefit of being documented and supported. Despite jQuery.isNaN() being undocumented, several projects on Github were using it. We have contacted them and asked that they use jQuery.isNumeric() or some other solution.

jQuery.event.proxy(): This undocumented and deprecated method has been removed. Users should be calling the documented jQuery.proxy method instead.

The jQuery Team, and Your Part

I want to recognize the incredible work of our regular team contributors in getting this release out the door, especially Timmy Willison (timmywil on Github), Corey Frang (gnarf), Rick Waldron (rwldrn), and Julian Aubourg (jaubourg). Karl Swedberg (kswedberg) and Addy Osmani (addyosmani) worked hard on getting the new documentation into shape on the API site. Also, thanks to Mike Sherov (mikesherov), a greenhorn contributor who has already created patches for several tricky bugs. Many thanks to all the others who reported bugs, submitted pull requests, reviewed commits, and in other ways made sure we did the best job we possibly could.

Still, we can always use more help, and that is where you can contribute. The simplest and most important thing you can do is occasionally test our work-in-progress against your code and your expectations. It’s always located at http://code.jquery.com/jquery-git.js and a fresh copy is built each time a new commit is made to our master branch at github.com. If you find a bug in a final release, test against jquery-git.js to see if it’s already been fixed. It’s easy as pie since jsFiddle.net offers an option to test your code with the jquery-git.js file as “jQuery (edge)”.

If you’d like to do more, we’d be glad to have you pitch in! We’ve written a document that can get you started with the process, and one or more of us are generally available in the #jquery-dev channel on IRC if you need more help or information.

jQuery 1.7 Change Log

The current change log of the 1.7 release.

Ajax

#9399: Deprecate jqXHR.success and jqXHR.error

Attributes

#5479: removeAttr: remove multiple attributes
#6743: map enctype to encoding, depending on browser
#10176: Injected script tag is evaluated twice
#10278: checkboxEl.attr(‘checked’) returns stale value after checkboxEl.click()
#10429: IE7 – invalid procedure call or argument when calling removeAttr(‘contenteditable’);
#10514: removeAttr does not remove the class attribute in IE6/7

Core

#6485: Solution for HTML5 in IE
#7102: Register jQuery as a CommonjS async module
#9453: $.inArray does not support fromIndex
#10478: Switch jQuery.isNaN to jQuery.isNumeric

Css

#10267: IE8 and window is(‘:visible’) crashes

Data

#7323: Allow removing multiple data keys at once with $.fn.removeData
#8909: $(element).data() will scan all attributes more than needed.
#8921: jQuery private data should stay private

Deferred

#8856: Request: deferred.isUnresolved()
#9033: try{ } finally{ } error in IE8
#9398: Proposal for Improved Deferreds

Dimensions

#9434: .outerWidth()/.outerHeight()/.innerWidth()/.innerHeight() should work on window and document

Effects

#5684: Effects: exception in animation callback causes endless loop
#6150: .stop sometimes doesn’t clear .delay
#6641: Calling stop() within animation finished callback causes other animations to freeze
#8685: Animations should keep track of animation state in order to properly address stacked animations
#9280: Allow multiple effect queues for animate()
#9548: animate does not work with fill-opacity css property for svg elements
#10445: Setting queue to true causes an error
#10497: .stop should allow choosing which queue to stop
#10622: .show() does not properly restore CSS-set “display” value

Event

#3368: event.metaKey should be assigned to event.ctrlKey on Non-Mac only
#6170: jQuery(window).scroll(); causes IE* to scroll to 0,0
#6319: Regression: stopPropagation inside change handlers in IE is incorrectly applied to keydown event
#6386: support data argument for live events via “event.special.live.add”
#6593: IE8: DOM 0 event handler called twice when a separate handler is attached via jQuery
#6667: submit event doesn’t delegate in IE* under certain conditions
#6903: special events need a way to determine whether they are being bound with .bind vs .live/.delegate
#6942: JQuery.event.fix causes unnecessary reflows in IE when handling key events
#7139: “hover” event alias should work for .bind as well as .live
#7161: Submit event on a form element not unbound properly in IE
#7444: Submitting form with “Enter” instead of button click on ie8 or ie7 triggers live submit event twice.
#8157: Focusing an already focused text field will prevent the change event from firing in IE
#8728: Event ‘mouseenter’ not firing when the element being left is removed on leaving
#8789: Meta: Event Property Hooks
#8858: Special events – _default method doesn’t have access to the `data` argument of the trigger method
#8866: IE8 input[type=file] delegated change event files only on blur
#8982: bind(“unload someOther”) => on unload, handler is not executed only once.
#9069: when hover over a child of an element, mouseleave fires when using live or delegate
#9279: delegate() bind does not handle mouseover/mouseout and mouseenter/mouseout correctly for selected elements
#9393: Unify and DRY out event system
#9593: Delegated submit event is not instanceof jQuery.Event in IE
#9724: Infinite loop in trigger function when window.parentNode is a DOM element
#9901: event.handleObj.namespace incorrect when using .delegate
#9933: jQuery.fn.toggle() should store state in private data object
#9951: Wrong order in .trigger() when DOM is modified in a handler
#10375: Do not include `type` in jQuery.event.props
#10438: Rename jQuery.event.propHooks => .fixHooks
#10468: Remove deprecated jQuery.event.guid and jQuery.event.proxy
#10489: Disconnected elements bubble to window on .trigger()
#10531: Consider removing layerX and layerY from $.event.props
#10563: jQuery.Event no longer contains the element that matched the selector in event delegation.
#10567: Delegated events incorrectly match class names
#10575: Breaking changes in live event propagation between 1.6.4 and 1.7rc1
#10576: jQuery1.7rc1 and jQueryMobile1.0rc2 – IE gets error in jqm triggerCustomEvent method

Manipulation

#6782: carefully allow more strings to use innerHTML
#7037: Duplicate mouseover and mouseout events added to cloned element.
#10501: HTML5 element “innerShiv” inconsistent across html()/append()

Misc

#10420: MouseWheel
#10553: Further reduction of minimal license header

Selector

#3144: Inconsistent cross-browser results from .text() method
#5637: Boolean (and Empty) Attribute Selectors Fail
#6863: faster getText
#7128: attribute selector is inconsistent between qSA and Sizzle due to use of DOM properties
#8539: Sizzle cache collision in browsers without querySelectorAll
#9261: Has Attribute not working in filter/children/siblings
#9570: Selector $(‘form[name=”..”]’) returns zero elements in IE8 under some conditions
#10178: $(window).is(“a”) >> Uncaught TypeError: Cannot call method ‘toLowerCase’ of undefined
#10315: Sizzle ignores seed argument when using positional selectors
#10562: siblings method returns unexpected elements when using Sizzle-invoking pseudo-selectors

Support

#5145: jQuery.support.opacity = false in the Chrome browser
#6809:

Announcing The jQuery Standards Team

Posted on October 24, 2011 by Addy Osmani

Today we’re happy to announce the creation of a new jQuery sub-team called the jQuery Standards Team to give web developers a voice in the standards process.

Introduction

We all know that web standards are important. They help ensure the code we write works across different technologies, for people of different abilities and most importantly across all browsers.

That said, how often do we all feel our voices, suggestions and ideas are heard by those groups responsible for defining these standards? The reality is that whilst many of us would like to see change, due to time restrictions and lengthy formal processes we’re unable to participate in standards discussions, get involved with writing specifications and contribute to meetings about the future of features. This makes it difficult for web developers to have a voice.

Yehuda Katz is team lead. Paul Irish joins him.

Another problem is that for those that do get involved with the process, it can often feel like participating on a particular thread in standards mailing lists has a limited impact because the web community is so fragmented. Browser vendors are very active on these lists and there’s a tremendous amount of institutional knowledge assumed in almost all threads. Implementors on those lists have their own venues for discussing areas of shared concerns, but web developers wishing to particpate don’t, with the exception of the accidental meetups at conferences.

The jQuery project would like to help change this – we want you to have a voice in how the future of the web is shaped.

The jQuery Standards Team

The jQuery Standards Team has three primary goals:

To represent the web developer community, in particular jQuery users, to standards bodies such as the W3C and TC39 with the intention of improving existing standards and standards in progress to better meet the needs of web developers.
To represent the web developer community, and especially jQuery users, to browser vendors with the intent of helping them identify standards that they should prioritize for implementing, and proofs of concept that they can build.
To help the jQuery project adopt new standards and browser features as appropriate.

This marks a large change in the way the web developer community is able to submit feedback and influence both standards bodies and specifications. By lowering the barrier of entry to having suggestions and issues about current implementations heard, we hope to encourage more developers with an interest in dealing with standards bodies and browser vendors an opportunity to participate in the process.

The jQuery Standards Team is driven by jQuery team members Yehuda Katz and Paul Irish who some of you may know. Yeuhda and Paul have extenstively worked with standards bodies and browser vendors in a number of capacities over the years, with their individual work on SproutCore and Chrome Developer Relations providing them additional perspectives that will be useful when advocating for the community.

You may be wondering why we feel this team deserves to represent the wider web developer community. Because jQuery is used by such a large percentage of sites on the web (over 50% of the top 10,000 sites), we have a good feel for what problems and challenges are commonly faced and what issues with existing implementations we need to try working around. As jQuery is also so focused on DOM-manipulation, the library offers a good source of information for known implementation issues and their (current) best solutions.

Although the current team is primarily composed of jQuery team members, we want to get as many developers passionate about standards and specifications involved with the team as possible. At the end of the day, the team’s goal is to to help identify web developers interested in the process and give us all a forum for both discussing the process, ideas and shared areas of concern. We believe that working together, we can all help build a better web.

Getting Involved

If you’re interested in getting involved with the jQuery Standards Team, the easiest way is to sign up for the Google Group. Similar to other jQuery sub-teams, there are going to be regular public meetings in #jquery-meeting on freenode (date TBA) to discuss how the team can be as effective as possible in promoting the needs of the web developer community.

You might have already seen Paul’s post What feature would improve the web? — if your feedback was captured there, you’ve already gotten involved. ;)

You can also report (or comment) on standard or specification issues in the issue tracker on the official team Github repo. If you’re posting new issues, try to identify problems with specs or standards that either exist or are currently being proposed. Here’s a great example of one such issue.

We want to collect well-specified and articulated issues with the web ecosystem and advocate for improvements with the standards bodies or vendors. For genuine issues, we’ll tag them accordingly (eg. W3C, TC39, Browser-vendor etc.) and if applicable, file tickets with the appropriate standards groups or browser vendors so you don’t have to.

Conclusions

By creating this new forum we hope to give a voice to the millions of web developers interested in contributing to the process, but without an easy way to do so. Please let us know what your thoughts are about the team as we want to improve it as much as possible. We look forward to hearing your comments, suggestions and ideas about both it and the standards process!

« Previous 1 … 5 6 7 8 9 … 13 Next »