Clientcide 2.1.0: updated for MooTools 1.2.3, bug fixes, a few new features
Today we released MooTools 1.2.3 and MooTools More 1.2.3.1. Both of these are, for the most part, bug fix releases with a few small features included. The big change is the deprecation of $ which is now replaced by document.id. This is a big change, and I suggest that you go read up on the MooTools blog about the details. It’s important to note that it won’t affect any of your code; all of these updates include no breaking changes.
The removal of $ as a dependency means that you can use MooTools with other frameworks (like jQuery) and MooTools won’t break. But if your code still uses $ then nothing will change unless you want to use MooTools with another framework that also uses $. Then you might want to consider using document.id, too.
For plugin authors, such as myself, you should update your code to use document.id. This will ensure that if someone using your plugins is using another library that overwrites $, then your plugin will still work. Note that you can easily upgrade an existing plugin by either searching and replacing $() for document.id() (be cautious that your search doesn’t catch $$()) or you can wrap your plugin in an enclosure:
var Widget = (function($){
return new Class({
initialize: function(element) {
this.element = $(element);
//...etc
}
});
})(document.id)
With the Clientcide conversion, I’ve opted for the former (to replace $ with document.id). In addition to this big change, the following other changes and features are included in 2.1.0:
- Universal: replacing all $() with document.id() (see MooTools 1.2.3)
- Autocompleter: defining splitter based on separator
- Autocompleter: Fixing autocompleter for Opera
- Class.Occlude, Class.ToElement: adding a compat layer for ToElement and Occlude
- Element.Delegation: Tweaked event delegation check to not extend elements unless match is found.
- Element.Delegation: Added an over 100x faster event delegation check that walks up the DOM tree from the target checking against the selector. Also removed mouseover and mouseout logic that seemed to be unnecessary.
- FixPNG: adding alternate fixpng suggestion (in docs)
- Fupdate: adding caption option to Fupdate
- Fupdate: adding method and emulation to fupdate request
- Fupdate.Prompt: making fupdate ajax prompt work with formvalidators applied inline in the html
- MenuSlider: adding isVisible method for MenuSlider
- SimpleSlideShow.Carousel: fixing overflow in SimpleSlideShow.Carousel for IE6
- StickyWin: added click-out and escape options for closing stickywin
- StickyWin: adding onDestroy event to StickyWin
- StickyWin.Alert: updating reference to StickyWin.alert > StickyWin.Alert
- StickyWin.Alert, StickyWin.Confirm, StickyWin.Prompt: refactoring the stickywin alert, confirm and (new) prompt shortcuts into classes
- StickyWin.Prompt: new class!
- StickyWin.UI.Pointy: several css and code tweaks to manage IE layout issues; making background image properties in StickyWin.UI.Pointy css attributes (in a <style> tag) to avoid this crazy bug: http://davidovitz.blogspot.com/2006/09/https-bug-in-ie.html
Follow @clientcide on twitter to get notified of new posts.
To follow me personally on twitter, follow @anutron.
June 19th, 2009 at 2:49 pm
Removing the $ dependence while keeping backwards-compatible is a huge win, IMHO. Not to mention the performance enhancements to Element.Delegation! We sure have come a long way since moo.fx :) Welcome 1.2.3!
June 19th, 2009 at 2:51 pm
Awesome! Having mootools compatible with other js frameworks is a huge step forward. Kudos to the mootools team!
June 19th, 2009 at 3:52 pm
This is awesome… Looking forward to getting everything installed and tested in all our Mootools code. Thanks for your hard work!
June 19th, 2009 at 7:03 pm
This is a huge step forward for the library, playing friendly with other libraries is great! This gets mootools ready for the jump to 2.0. I’m looking forward to it. Great work guys!
June 20th, 2009 at 12:37 am
Great!
Although from my point of view not really needed, compatibility with other frameworks is often cited as the major drawback of MooTools (see just discussion atjqueryvsmootools).
Slightly offtopic, but how do you proceed with your new MooTools book, Aaron? The first one was real joy to read and the source of much wisdom about MooTools and javascript; now I’m waiting impatiently for the release of the second.
June 20th, 2009 at 11:52 am
The book is essentially complete, but MooTools 2.0 isn’t. So the book must wait.