jQuery 1.6 Beta 1 Released
We’re nearing the completion of jQuery 1.6! We want to get a beta out so that everyone can start testing the code in their applications, making sure that there are no major problems.
jQuery 1.6 Beta 1
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.6 Beta 1.
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.6 Beta 1 Change Log
The current change log of the 1.6 release.
- #6782 Optimizes regex for innerHTML to allow more html snippets to use faster method.
- #7328 When getting data- attributes, after-cap any embedded dashes per the W3C HTML5 specs.
- #4146 Fixing inconsistency with width/height on inputs.
- #7345 Adds support for explicit/relative string values in .css().
- #7783 Fixes $.proxy to work like (and use) Function.prototype.bind
- #8753 Allows special properties to be explicitly defined on jQuery.Event objects.
- #7587 Bypass regexp filter on $.parseJSON and use native thrown exceptions if window.JSON.parse is available.
- #8150 Fixes an issue where if removing the width and height attributes in IE6/7, setting to “” actually sets to 0 instead of auto.
- #6562 Fixes an issue where if you have a DOM node with the ID of ‘target’ and you try and set a target it fails.
- #8744 Makes sure script transport abort method actually removes the script tag even if readyState exists.
- #8712 Bubble custom events to the window when they are triggered.
- #8635 Fixes an uncaught exception in Firefox and removes unnecessary “manual” garbage collection.
- #8568 Fixes an issue where live event callbacks can get out of order in the event liveHandler function.
- #8417 Disables the JSONP replacement for $.ajax() JSON POST.
- #8099 Fixes an issue where SPAN elements become block level on show().
- #8593 Fixes an issue where DOM 0 event handlers are called twice when a separate handler is attached via jQuery
- #8402 Fixes an issue where browsers implementing window.getComputedStyle completely ignore the “fixed property” in jQuery.css(). This makes the implementation of jQuery.cssProps more generic.
- #8401 and #8403 .Fixes an issue where jQuery “bulldozes” other IE filters when setting opacity
- #7071 Corrects an issue where accessing the ‘type’ property on VML elements fails on IE
- #4321 Fixes an issue where $(“#”) returns “undefined” and an exception on Opera 9.6.
- #7883 Just like .bind, .delegate (and .live) now accept false as a shortcut for function(){return false;}.
- #2773 $.fn.is and $.fn.not now accept DOM elements and jQuery collections.
- #8777 undelegate() now accepts custom namespaced events.
- #3116 .attr() now also works with read only interfaces of the SVG specification.
- #8732 Changes feature detection for focusin event support so that IE9 won’t have duplicate vents.
- #7369 It is now possible to use .closest() on disconnected nodes with attributes.
- #4366 Fixes an issue where $.each was failing when passed document.styleSheets in IE.
- #7931 Corrects an issue where both the $.fn.scrollTop and $.fn.scrollLeft setters returned null when called on an empty jQuery object.
- #8101 We now use requestAnimationFrame instead of setInterval for animations when it’s available
- #8018 Fixes an issue where unsafe access to frameElement causes errors in crossdomain (i)frames
- #6180 jQuery.clean no longer affects or modifies script tags which are not of the type text/javascript
- #3685 Corrects a previous failure when selecting forms with an element named “name”
- #8790 For cases where an event that is triggered is not native (ie. should not have inline handlers) we should bail out immediately for optimization purposes
- #8814 Fixed a minor issue where in core.js, we don’t need to check for indexOf in the fallback inArray definition.
- #7472 and #3113 Fixes an issue where if attribute names in forms share the same names as attribute types (eg, id, name etc) a conflict was being experienced
- #7054 Ensures that the DOM element ref in an event handler is removed by cleanData to avoid an IE6/7/8 memory leak.
- #8418 Fixes an issue where attr(“name”,”value”) is not working to set name attribute value in IE 7
- #7996 Fixes a Safari 5.0.3 bug when trying to use jQuery’s .attr() on a script tag to access an attribute named “event”.
- #8772 Fixes an issue where IE9 fails to gracefully handle the setting of unsupported input types such as ‘range’.
- #4283 As part of the .attr() rewrite, false will remove Boolean attributes such as checked.
- #8699 .attr() no longer returns -1 on missing attributes instead of undefined.
- #6837 Corrects an issue where IE fails to return the correct value of the default/first item in the select after a form reset, instead returning an empty string
- #4464 Fixes a bug where IE was unable to get the width attribute of detached IMG elements
- #7485 Fixes an inconsistency where a selector doesn’t return all elements which have the attribute even if upon checking with the attr() method it returns a value.
I like new jquery version
I love lamp.
Nice too see these .attr() changes coming in! Thanks for all your hard work
I am happy about the proxy-enhancement (#7783).
Unfortunately Ben Almans Pub/Sub didn’t make it… I think what quite some people would see is some kind of jQueryEE (“Dojo-light”) with a standardized Templating Engine, Dependency Management (defer.js/require.js etc.) and traditional Class-based Inheritance built-in. The emphasis is on “built-in”, which means interchangeability. Javascript came quite for (thanks to jQuery and others) but it still suffers from too many choices.
My 2 cents.
#8755 is still an issue.
Any new features?
One ticket in this list, #7061, is NOT marked as fixed, according to http://bugs.jquery.com/ticket/7061.
How about a version that supports only IE8 and higher, FF4 and reasonable versions of the modern browsers?
???1.5.2???????
jQuery is getting bigger in file size in every version, mostly due to fixes, but also new features. I wouldn’t call jQuery bloated (as it doesn’t contain an email client yet), but there are a lot of features I don’t use.
Can we expect modularity or custom builds anytime soon?
I am with Blaise Kal, i think jQuery needs to become modular, i am the same i do not really use all the thing’s jquery has to offer.
Check out the instructions in git hub,
I think you can build your own and customised functions, it’s just some dependencies.
https://github.com/jquery/jquery
Thanks Shawn for your reply.
“Some dependencies” sounds like entering a world of pain ;)
I was hoping jQuery would get some kind of build system like jQuery UI, where I can happily select components, without having to worry about dependencies or having to dig through code or documentation myself.
@Blase – The best thing is everyone to use the full jQuery download from a CDN – say the Google CDN: http://ajax.googleapis.com/ajax/libs/jquery/
Since the CDN sets the Expires http header to 1 year in advance your jQuery driven Web pages may not need to download it at all – it might have been already cached while visiting other web sites. Now jQuery is used from more than 40% of the top 10 k sites, just few days after a new jQuery release it gets cached in almost all actively used browsers.
If everyone starts to use a different build the advantage of shared cache is largely lost.
in which release animate will suport browser native transform and transition ?
@Filip Babalievsky, Yes but using a external CDN is often 10x slower just to get a 302 response because of ping etc. Also I find the some times requests fail altogether.
Is there any plans on making jquery like jquery ui where we can select the components we need?
@Petah, when using external CDN for a very popular library as jQuery even a ping (i.e. a conditional GET) may not be needed. Your visitor’s browsers might have the library already cached.
It differs when you develop having both browser and server on the same machine and have to hit often “refresh”(e.g F5) for the pages you develop.
Each refresh would include conditional GET-s for all resources on your page, but in “production” your visitors normally don’t do “refresh” – so no waiting for 304 response or for reload.
Also, bug #2616 is included in this release. jQuery.map now supports objects :D
http://bugs.jquery.com/ticket/2616
@Petah, for local development I use some kind of HTTP Proxy (e.g. Charles) that maps remote files (like jQuery) to local files. This speeds up loading time alot and I don’t need to change the script src during development (or make them conditional).
Why not use the CDN version and a local fallback, á la html5boilerplate?
any new features included other than bug fixes?
Just checked google’s hosted jquery, and it returned the following headers. This means that most of the time your browser won’t even make another roundtrip after it already has it in local cache — not even to get a 304 response. It’s just there.
Expires Tue, 24 Apr 2012 18:47:26 GMT
Cache-Control public, max-age=31536000
CDN is the best solution to combat jquery filesize… if it’s even an issue at all…
Jquery inArray() function:
for ( var i = 0, length = array.length; i = 0;) {
if ( array[ i ] === elem ) {
return i;
}
}
But this Faster because 0 – constant, length – variable.
for (var i = array.length; –i >= 0;) { if ( array[ i ] === elem ) {return i; }}
I was hoping jQuery would get some kind of build system like jQuery UI, where I can happily select components, without having to worry about dependencies or having to dig through code or documentation myself.
jQuery is used from more than 40% of the top 10 k sites, just few days after a new jQuery release it gets cached in almost all actively used browsers.
If everyone starts to use a different build the advantage of shared cache is largely lost.