Slideshow 2

Slideshow 2 by Aeron Glemann is an outstanding photo / slideshow plugin that offers a plethora of options and features — many more than you’d find with the average slideshow or lightbox. Slideshow 2 features Robert Penner easing transitions, photo delays, duration settings, the ability to make Slideshow 2 a lightbox, and an on-photo control panel.

http://www.electricprism.com/aeron/slideshow/

MooTools FileManager

Created by MooTools Core Developer Christoph Pojer, MooTools FileManager is a MooTools-driven file manager that allows for drag and drop file management, Ajax directory loading, file content previews, and much more.

http://og5.net/christoph/article/MooTools_based_FileManager

Moousture

Moousture is a MooTools Mouse Gesture library created by Zohaib Sibt-e-Hassan. Moousture allows you to create multiple geture patterns and assign them to any number of elements. http://neofreeman.freepgs.com/Moousture/

Fancy Upload 3

Fancy Upload 3 is the newest iteration of Harlad Kirschner’s popular Flash/MooTools upload tool. Fancy Upload 3 features file-specific options, an additional IFrame-based uploader, Flash 9 and 10 compatibility, and the same base features that made Fancy Upload a must-have plugin.

http://digitarald.de/project/fancyupload/

MooTools.Mode For Coda

If you spend hours with MooTools and the Coda text editor, you’ll love the MooTools.Mode Syntax Mode add-in. This package created by José Prado is free and easy to install.

http://pradador.com/code/coda/moomode.html

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your future plugins in upcoming posts!

MooTools 1.2.3 DOM stuff doesn’t depend on the presence of $ anymore. The method that used to be $ is now called document.id (short for identify). The method $ is still assigned when not already present in the page, and aliased to document.id.

But let me show you how it works:

Let’s say you have mootools.js and a fictional JS library called jLib.js. Both use a method called $.

This is what it used to happen:

Scenario 1: Include mootools first:

<script type="text/javascript" src="mootools.js" />
<script type="text/javascript" src="jLib.js" />

jLib would “steal” the $ method from MooTools. MooTools doesn’t work unless jLib has some sort of no-conflict mode of its own that will allow you to prevent it from “stealing” $ from MooTools.

Scenario 2: Include jLib first:

<script type="text/javascript" src="jLib.js" />
<script type="text/javascript" src="mootools.js" />

MooTools would “steal” the $ method from jLib, which may or may not work without it.

What happens now:

Scenario 1: Include MooTools first:

<script type="text/javascript" src="mootools.js" />
<script type="text/javascript" src="jLib.js" />

MooTools checks if a method called $ exists; if not, it defines it. In this scenario, MooTools defines it as it doesn’t find anything named $, being included first. jLib “steals” the $ method from MooTools. MooTools doesn’t care. MooTools now doesnt need $ to properly function. You can regain control of $ simply by reassigning it to its alias ($ = document.id).

Scenario 2: Include jLib first:

<script type="text/javascript" src="jLib.js" />
<script type="text/javascript" src="mootools.js" />

MooTools checks if a method called $ exists. It does find it, being included last, therefore it doesn’t define it. You can directly use document.id() or assign your own var to it, or manually assign $ to document.id, if you would like MooTools to have control of it.

As you can see, it’s pretty straightforward. In short, MooTools doesn’t need $ to function anymore, and doesn’t steal it from other frameworks when included after them.

Plugins

The above applies for MooTools-Core and MooTools-More. However, MooTools plugins use the $ method, therefore, while not breaking MooTools by including jLib, you will break the MooTools plugins. If you desperately need plugins to be multiple-framework compatible, and you the other frameworks to have control of $, there are a few things you can do.

The first, most obvious and recommended option is to replace every call to $() with document.id() by hand. It doesn’t take more than 10 seconds with a simple find and replace. This is probably what plugin authors should do, if they wish their plugin to be dollar-safe.

Another option is to encapsulate the plugin using a closure. This might come handy if you are processing a plugin that isn’t yours:

var X = new Class({
    initialize: function(element){
        this.element = $(element);
    }
});

it should become:

(function(){

    var $ = document.id;

    this.X = new Class({
        initialize: function(element){
            this.element = $(element);
        }
    });

})();

As you can see, we’ve simply assigned $ as a local variable, using a closure. Everything in that closure will use document.id as its $ method. Remember to export the global variables though, as vars defined in the closure will stay private. I like to export globals using this., but you can use window. as well.

Please note that MooTools will probably remain incompatible with other frameworks that modify native prototypes, as there will probably be more name clashes. This isn’t a cross-framework compatible MooTools version by any means, nor does it want to be. The whole point is not to “steal” the dollar function from other libraries.

And that’s pretty much it about the Dollar Safe Mode™ in MooTools 1.2.3.

The value in making this change is allowing developers to use more than one framework within a page (which is NOT something we recommend or endorse, but we recognize this is not always under the developer’s control). Not relying on the dollar function prevents the need for jQuery.noConflict() when using jQuery and MooTools together, for example. If no other framework is detected, however, $ will be assigned to MooTools. This means that all of your current MooTools code WILL NOT break. It does, however, mean that if you want to use MooTools and jQuery together (without using jQuery’s noConflict mode), instead of using $ in your MooTools code, you’ll have to use document.id().

If you want your MooTools plugins to be cross-framework compatible, you’ll have to replace all the instances of $ with document.id().This change only applies if you’re using more than one framework on your pages. If all you use is MooTools, nothing will change for you. Look forward to more details about Framework compatibility mode in a future post.

MooTools Core & More Updates

While we encourage you to browse LightHouse and the histories for MooTools Core and MooTools More to get the most detailed list of changes, the following significant updates were committed in MooTools 1.2.3:

Core

• Element: MooTools compatibility mode: the $ function is only defined if no pre-existing $ function is found. If an existing $ function is found, you can use document.id()
• Element: changed internal instances of $ to document.id
• Core: fix for server-side MS JScript 5.x; makes MooTools more friendly for server side programming
• Class: Class doesn’t require Browser, removed from scripts.json
• Element: Fixes for set/get Property
• Element.Dimensions: fix for webkit body.scrollTop inconsistency, getBoundingClientRect used whenever possible (not just for Trident), renaming element.position to element.setPosition; adding docs for the method; alias is included in-line for compatibility
• Hash: Hash extend no longer uses the window if no arguments supplied
• Request: clearing Request readystate before calling success or failure;
• Selectors: Added :enabled pseudoselector, was in the Docs but not implemented.
• Docs: Fixed docs headers for first-child, last-child, and only-child.
• Internal: UnitTester test suite is now a git submodule
• Numerous small fixes, speed improvements, documentation tweaks, etc.

More

• Per the change in -core, $ is no longer used (uses document.id instead)
• Element.Measure: trying cssText solution for Element.expose (again).
• Element.Forms: swapping feature detection for browser support per
• Date: Massive refactoring of Date.js and Date.Extras.js
• Drag.Move: Fixing drag with grid issues
• IframeShim: altering zindex assignment in IframeShim to better ensure that it’s always underneath the shimmed element, updating Iframeshim’s empty document creation; fixes https issues in IE6
• FormValidator: reworking formvalidator scroll-to logic to be a little more efficient
• OverText: preventing overtext from focusing on inputs except when they are interacted with (so OverText.update() does not focus an input);now stops polling when elements are hidden (when polling is enabled)
• Fx.Scroll: adding scrollIntoView method - scrolls an element so that it is completely visible; if below the view, scrolls down until it is at the bottom of the screen, if above, scrolls up until it is at the top.
• JSONP: was calling (the deprecated) this.request instead of this.send during retries
• URI: Adding set(‘data’, obj) to set
• Assets: adding error callback for Assets.images
• Tips: removing dependency for Element.Measure for Tips; updating CSS class name in OverText
• Numerous small fixes, speed improvements, documentation tweaks, etc.

MooTools 2.0 is on the Horizon

As mentioned above, 1.2.3 is likely the last update for MooTools 1.2. MooTools 2.0 will introduce numerous performance improvements and new features. We want to stress that MooTools 2.0 will feature 100% compatibility with MooTools 1.2.x.

Thank You!

Thank you for the bug fixes, feature requests, and support during MooTools’ 1.* lifetime. You, the MooTools community, have helped make this framework better with every bug found and question asked on the forum. We look forward to releasing MooTools 2.0 this summer and getting feedback from everyone in this awesome community.

Last week we announced that MooTools merchandise was available for purchase. We’ve seen a great response to the announcement and we’ve received a solid amount of orders. Thank you for your continued support! Now it’s time for us to show you our appreciation.

The MooTools team would like to announce Faces of Moo. Faces of Moo is where we post photos of you and fellow community members wearing your MooTools shirts, hats, and hoodies. What better way to strengthen the MooTools community than by showing its talented members wearing their Moo colors?

What do you need from me?

Please provide the following items:

• Name (if you feel comfortable sharing)
• Location (ex: “Los Angeles, CA, USA”)
• Website URL (if you have one)
• Photo (we will crop/resize as needed, so please provide a large photo)

Easy enough, right?

Where do I send my information?

Please send the information above to mootoolspeople@gmail.com. We’ll get you up on the site as soon as we can.

Thank you!

Again — thank you, thank you, thank you for all of your support and look forward to bigger and better things from the MooTools team!

• T-Shirts
• Hoodies
• Laptop Bags
• Hats

You can purchase these stylish items at: http://mootools.net/merch

Feedback wanted!

Can you think of merchandise you’d like to see in the MooTools store? Be sure to let us know in the comments below!

What are you waiting for?

Grab your MooTools merchandise and represent your framework!

Note: The above link will attempt to send you to the correct store based upon your location. If the above link fails, please visit http://mad4milk.spreadshirt.com/ if you are in the US and http://mad4milk.spreadshirt.net/ if you are in Europe.

• Removed debug statement that enabled IframeShim in all browsers by default
• Fixed a few docs typos
• Removed UTF-8 charset signature on String.QueryString and URI.Relative
• Assets.image now have an onError option and handle image load failure more gracefully
• FormValidator.Inline had issues displaying some of it’s validators when input values changed
• OverText now allows you to specify the element type for the label test (defaults to “label”)
• Fixed an issue with addRequests in Request.Queue; the arguments were reversed (addQueue still worked fine though)

None of these changes should affect your usage of the class, except, possibly, the change to OverText, as the element it previously created for the labels was a div. If you styled these with css and referenced the tag name, you’ll either need to update your css reference or pass in element: “div” as an option when you invoke the class.

Core

MooTools 1.2.2 is a mainly a bug fix release but it also includes an almost entirely new Class.js. The reasoning behind this is that the old Class.js didn’t play nicely with some advanced usages of this.parent() present in the new MooTools-More. We already had the script ready and tested in the MooTools 2.0 branch so we simply “backported” it to 1.2.2. Other than providing the parent fixes, the new Class also features a much more robust inheritance model, especially when dealing with objects.

For example, the objects you implement now in a class are merged if an object with the same name is found in the class prototype:

var Animal = new Class({
    options: {
        color: 'brown',
        says: 'hissss'
    }
});

Animal.implement('options', {says: 'meow'});

// Animal.prototype.options is now {says: 'meow', color: 'brown'};

This is especially useful when overriding default options in classes, such as Request.

Another object-oriented feature we introduced is that now sub-objects are actually inherited Parent-to-Child. If you implement a new option in Animal, then Cat, which is a subclass of Animal, will get the new option as well, and so will every instance already existing. An example:

var Cat = new Class({
    Extends: Animal
});

var kitty = new Cat();

Animal.implement('options', {nu: 'one'});

Cat.prototype.options.nu == 'one' //true
kitty.options.nu == 'one' //true

This obviously also applies to methods.

Additional changes to the MooTools Core in 1.2.2 are mostly minor bug fixes.

More

One of the new features of MooTools-More, since the last RC, is that it is now possible access the previous state of overwritten methods of classes through Class.refractor. An example:

var Cat = new Class({
    energy: 0,
        eat: function(){
            this.energy++;
    }
});

Cat = Class.refactor(Cat, {
    eat: function(){
        this.previous(); //energy++!
        alert("this cat has " + this.energy + " energy");
    }
});

This functionality allows users to integrate seamlessly with existing classes, and add to existing methods without the need to subclass.

We’re considering some way to make this behavior more generic for a possible inclusion in MooTools-Core 2.0.

The first RC of MooTools-More produced a lot of feedback and contributions that we’ve integrated as we prepared for our full release. Following this full release of the new MooTools More plugins, we’ll begin adding new features quickly and regularly with what we hope will be biweekly releases.

The MooTools project has been around for quite some time now. We’ve seen a few releases, some great, some less great (1.0). We’ve coded tons of plug-ins, scripts, websites, applications and desktop applications using our beloved MooTools. However, the community is really starting to get tired, tired of this project name. I mean, seriously, we’re really fed up with cows. We even tried to “sell” it as My Object Oriented Tools, but we all know that’s a stretch, and a pretty bad one.

Therefore, I officially announce to the world that from now on MooTools will be known as jTools. This is the totally logical choice for our new name, since you know, the j stands for JavaScript, and well, MooTools is written in JavaScript. It’s so obvious I can’t really understand why everyone doesn’t just prepend j into their JavaScript project name. Anyways, I hope you’ll like it, as this new name is very likely to stick around pretty much forever! On another note, we are also renaming MooTools More to jMore, MooTools Core to jCore and Aaron is renaming Clientcide to jCide.

Also, we’re going to remove internet explorer 6 support from in next minor version of jTools. I wish I could tell you more about this decision, but it’s far less important than the groundbreaking name change, so I’ll leave it for another day.

Cheers!

Today, I have an answer. The only way to give you a better MooTools is to give you more of it. It’s that awesome. Today, we’re making MooTools awesomer.

We give you the new and improved MooTools More - the official plugin collection for MooTools. The plugins we are releasing today take the fifteen files previously in MooTools More and triple them. That’s three times the awesome!

What’s in it you ask? Well, let me tell you. The new and improved -more currently includes:

• Class extensions including a Binds mutator, easier refactoring, chain pausing and more.
• New Native extensions including more love for String and Array, plus a fully featured Date Native and a URI extension to make managing links downright fun.
• More Element love with help for managing text selection and relative positioning (put this box’s lower right corner next to the upper right corner of that other box…)
• Form love including a robust and extensible form validator and a class for displaying hint text over an input.
• Extended Request functionality including JSONP support and Queuing.
• Support for language localization for classes that output text (days of the month, months of the year, form validation errors, etc)

Oh, and we’ve already translated the text content in these new plugins (Date and FormValidator specifically) into half a dozen languages thanks to all the helpful folks in the MooTools-Lang user group (do you know a language other than English? Want to help? Here ya go).

I know, you can barely contain your excitement. Us too! Surely, you ask, there must be a catch to all this awesomeness. Does it cost four easy installments of $19.99? Shipping and handling? Must you sign an oath? Nay! It’s free for the taking.

But there are a Few Catches

First, today’s release is just the beta - the first release candidate (RC1). This means that you will certainly encounter problems, which would imply that it’s not 100% awesome (you are wrong! It is 100% awesome - when the beta is finished and we officially release it it will be 125% awesome).

But yes, you may encounter bugs. In this case, you will need to file it in the shiny new MooTools-More dedicated Lighthouse. Industrious types are encouraged to pull the repository from github and try and fix things themselves - helping hands are always appreciated.

In addition to this, the docs for the beta are in a different location (links at the bottom). The search in these docs still points to the google search for the current docs, so the new stuff won’t be returned if you use the search.

Also note that there is not a compatibility layer yet written for this release. There are only a handful of items from the previous files that were in MooTools More. For those of you using the Clientcide libraries, you’ll see a lot of familiar scripts on the list, and there are numerous changes between the versions on Clientcide and the versions here. You can see the list of breaking changes in the readme.

Enough! Give It To Me!!!

Ok, ok, you want links? Here you are:

• The Docs for MooTools More RC1
• Download MooTools More RC1

How You Can Help

There are several things you can do to pitch in. First, you can run the tests in all the browsers you have access to. There are two types of tests:

• The Specs Tests
• The User Tests

Running through these in your browsers and reporting anything that seems wonky will help us tremendously. If you know a language that hasn’t yet had the translation written for Date or FormValidator, you can, as mentioned previously, jump into the MooTools-Lang group and help out with that.

More to Come

MooTools More is now it’s own official project which means its release schedule is no longer tied to MooTools Core. Once this release candidate is fully released (hopefully in the next week or so) expect to see new plugins arrive every week or two. Our objective is to quickly grow the plugins available here as well as address bugs in MooTools More constantly. We have a long list of functionality already lined up for future releases. This is only the beginning! If you want to get involved, read more on the MooTools More wiki.

Thanks

Special thanks go to the MooTools More team zilenCe (Christoph Pojer), devthought (Guillermo Rauch), David Walsh (er, David Walsh), and the numerous others who helped in the development of this release. Seriously, there were a lot of people who chipped in. You can too, if you like.

MooTools 1.3

As discussed elsewhere MooTools 1.3 is on the horizon and features numerous changes that will interest you. The caveate here is that all of this is subject to change, as the work is still very much underway.

1. Class is getting a rewrite that should make it both less likely to encounter browser issues but will also empower you to do some cool stuff like post- and pre-initilization mutators and inherit object properties from prototypes (the current Class breaks this inheritance link for things like options to prevent pollution across instances).
2. There is a new Type constructor that has numerous methods that help you manage objects. For instance, the $type method is now Type.of and there are methods for each type (Type.isString(‘foo’) === true). In addition, most Native instances will have a .from method (Array.from(iterable)).
3. Most of the $method functions are moving into better places in the framework. This means that $type is now Type.of, $empty is Function.empty, $lambda is Function.lambda, $random becomes Number.random, etc. Not all the $methods will get this treatment as there are at least a few of them that don’t really go anywhere. We’re still discussing what to do with them ($pick, $each, $defined, etc).
4. Event Delegation will make it’s way officially into the framework (there are some implementations out there of this already).
5. Hash, Cookie, and Swiff are all likely moving into mootools-more. The thinking here is that the Core doesn’t need these things to function and while they are useful features of MooTools, they aren’t needed by everyone.
6. In a new policy change, the default pre-built version of the MooTools core will come with the compatibility layer for the previous version built in. This means that if you have a site running MooTools 1.2 you should be able to just drop in 1.3 and continue partying. You’ll want to start using the MooTools 1.3 syntax going forward, but in general, upgrading should be a lot easier.
7. Various small bug fixes and the like.

As a side note, we’ll point out that while there are some organizational changes to the library with numerous methods being renamed and moved, by and large the changes are all search-and-replace friendly. Other changes, like those to Class, aren’t likely to affect existing code.

MooTools -more Has a Posse

For the past year or more the focus among the MooTools developer team has been to continue to refine the MooTools core. The changes made there are mostly refinement and enrichment, but to a great extent are not really about new features. With MooTools 1.2 the various interface oriented files were split into mootools-more and haven’t really been touched in a long time other than to fix bugs and whatnot.

Starting today this split is becoming even more pronounced in that the -more files are going to be considered their own project. To that end these plugins and new ones will have their own development team and their own mission, namely, to expose to the MooTools community the plugins authored by the MooTools -more development team. By default, this group is defined as the developers who have been contributing to MooTools for a while now, but the scope of the files will broaden greatly. The definition for a good plugin for mootools-more will be “Any well written plugin that serves a reasonable use case that is contributed by someone willing to continue contributing to mootools-more.” Simply put, expect to see lots and lots more plugins for your use.

To manage this new project and team I (Aaron) have been tapped to put together the development team. If you’ve ever visited my site (Clientcide) to download plugins you’ll know that I have a lot to share. In the coming weeks expect to see a lot of these plugins (not all of them) move into mootools-more and become official MooTools plugins. Expect to see more plugins from MooTools contributors as well as plugins written by others who are interested in joining the team. We mean you. Expect more on how you can help out in the coming weeks as well as an official roadmap.

2009 is going to be a great year to develop with MooTools. We’re very excited and hope you are too.

Resig wrote Tom an email, saying that he would be pleased if MooTools joined the other frameworks by implementing Sizzle in its codebase, replacing our own selectors engine. I don’t really know how many frameworks are actually thinking of using Sizzle in place of their own selectors code, as the only source I can find for this is Ajaxian.

Their information about Dojo wasn’t correct, so I’m assuming that information about other frameworks is incorrect as well. I do know that Dojo is considering including Sizzle as part of the Dojo foundation, based on an email Dylan Schiemann wrote to Aaron Newton. As I understand it, Sizzle would become a Dojo Foundation project, with the ultimate goal of including it into Dojo Toolkit. They have this idea of having the major framework developers all contribute to a unified CSS selector engine.

Now that you know the general picture, let me explain why this is a bad idea not only for MooTools, but for any framework other than Dojo and jQuery.

There are several reasons why a project like MooTools would never include a third party library like Sizzle in its codebase. First of all, we already have a very fast, very manageable and solid CSS selector engine in place. I worked on it a lot, I know how it works, and I know that if it ever needs a fix, every MooTools collaborator can just git it and fix it, right away. Every Mootools collaborator knows how MooTools works, what our code practices are, and how to submit either a patch (if they don’t have Git credentials), or patching the code themselves.

With Sizzle, I would have to submit a patch to the Dojo codebase, which would have to be passed through Dojo. This leaves the possibility that the patch could be rejected, leaving us with a part of our library that doesn’t fit with our core philosophies.

It is largely a matter of code itself. MooTools has its own very strict code rules and conventions. For example, everyone working on MooTools knows that if they have to detect Explorer, they need to use Browser.Engine.trident, everywhere. If a developer doesn’t do that, he would probably be yelled at by myself. By including a standalone library like Sizzle, we would be breaking our own rules. MooTools does a great deal of work by abstracting common functionality and reusing these abstraction everywhere, for both ease of update and code readability. By including a standalone library like Sizzle, we would be breaking this paradigm that has worked so well for us so far. But most of all, we would be breaking the very essence of MooTools, being one single entity, perfectly balanced and in harmony with all of its parts.

Sizzle itself is well written, don’t get me wrong, but I honestly don’t think it’s any better that what we currently have. First, Sizzle is a very big script in size compared to our selectors engine.

Second, it (unintentionally) highlights a shortcoming in SlickSpeed by caching every expression’s results. John has a speed folder in his Sizzle GitHub repository, where he is comparing a selectors engine to real-world frameworks. SlickSpeed runs every expression five times, recording the median result. Since Sizzle caches the results, Sizzle results will always come out five times faster than anything else, assuming the code is as efficient as every other framework’s.

Third, as some of you might already know, MooTools post-processes every node resulting from any query. This tends to make things slower. Sizzle however is a pure engine, therefore makes no post-processing at all. This results in a very unfair comparison.

In an effort to test the true efficiency of our CSS selectors engines, I have made a modification to SlickSpeed, so that it runs every test only once, and a couple of modifications to the MooTools code. This special testing version of MooTools no longer “extends” the resulting nodes (I did that by simply adding a method that passes an optional parameter to the default function getElements, as I cannot pass parameters using SlickSpeed), and it uses querySelectorAll where available, just like Sizzle does. This way we can have a true comparison between engines, instead of frameworks and engines.

Feel free to test my results in every browser available to you. As you can see, the Sizzle engine is slower in many browsers.

Even assuming Sizzle were faster than MooTools in every test, it would be unwise to adopt it.

The Dojo Foundation and jQuery have it easy. The Dojo people can just work on their own code repositories, where everyone knows what to do and how to contribute. It’s basically the same thing for jQuery: Sizzle is copyrighted by John Resig. He will always have a way to add/remove/modify whatever he pleases. Us outsiders, however, won’t have it as pretty. We would have to gain the approval of the Sizzle project before making changes, limiting the power we have over our own codebase. As with any project, there is always a chance that a patch that we submit won’t be accepted. In that case, we’re stuck with code we don’t like.

This centralization of code would create a dangerous precedent, eliminating competition in the marketplace and choices for developers who rely on frameworks. Quoting Wikipedia:

[A] monopoly exists when a specific individual or enterprise has sufficient control over a particular product or service to determine significantly the terms on which other individuals shall have access to it.

It is often argued that monopolies tend to become less efficient and innovative over time, becoming “complacent giants”, because they do not have to be efficient or innovative to compete in the marketplace. Sometimes this very loss of psychology efficiency can raise a potential competitor’s value enough to overcome market entry barriers, or provide incentive for research and investment into new alternatives.

I’m not saying that John Resig seeks a monopoly over CSS selector engines, but that’s sure what it looks like. Competition and innovation will stop if everyone uses the same piece of code. Yes, competition and innovation.

Sooner or later, it will become too cumbersome trying to make Sizzle, or any other “shared component” fit our selfish, OCD-driven developer needs. No sane contributor will be eager to take the extra steps to contribute to different parts of our libraries, and in the end we’ll have contributors completely ignoring the selector side of it. Personally, I would never ever take my developers through the process of learning two different sets of project guidelines just because they want to contribute to the selector engine and make modifications.

As I’ve said, MooTools developers know MooTools stuff. That’s what MooTools is all about: MooTools stuff. This is the way it should be for every other framework, otherwise, it’s kinda pointless having your own. Unifying portions of frameworks would be the end of independent innovation, and we would become reliant on John and Dojo to make it better.

Or we could fork it, which would negate any proposed benefits, like having all developers of all frameworks work on a common piece of code.

If MooTools were allowed to submit any code which we wanted, we would have to assume that the same would be true of all other framework projects adopting Sizzle. Without any serious form of control, it would soon become a monster script that fits nobody’s needs.

Citing a bold sentence in this Ajaxian article:

It’s very likely that Sizzle will eventually expand into other areas of JavaScript libraries (such as DOM manipulation and event binding).

Let’s face it: every selector engine, every part of our libraries has benefited from the others. Where they diverge is not an indicator of which framework is superior to another. Rather, they are differences in philosophy. If everyone were to use the same, shared codebase, these awesome open source contributions and general advancements will stop, and users wouldn’t be able to choose the approach which works best for them. I don’t want to see that happening.

The very reason we have many JavaScript frameworks is because we want to do the same things, differently. Each one has its own way to code, its own way of solving problems. By including something that’s not MooTools in MooTools, we would make MooTools be less MooTools (and more jQuery, in this case).

So, if using one shared selector engine is ok, where do we draw the line? Is it ok to use a shared DOM manipulation library, or a shared event library? What makes our framework ours? If we start replacing core parts by outsourcing them to Dojo, our frameworks will just be a dull layer for code we didn’t even write, and we will lose credibility.

Why use a layer when I can just use the real deal? Why would I use MooTools, if it’s just a layer for Dojo or jQuery code? Don’t even try and justify that it’s not, because the code would be on Dojo servers, administered by Dojo foundation rules. Its Dojo’s. We at MooTools prefer MooTools code, by MooTools coding standards and rules. And I’d be surprised if many frameworks are willing to give this all away for nothing.

What’s new?

Element.Properties.html (element.set('html', html);) now works even with select and table elements in Internet Explorer. Element:clone is also now faster than ever, and retains the values of form elements being cloned. A lot of work has also been done to fix some bugs in Class.js, and Safari 2 support is now back. With the help of Daniel Steigerwald, we’ve also cleaned up quite a few memory leaks in IE related to events and Element storage, and destroyed elements are now more effectively destroyed.

For a complete list of changes, see the changelog on GitHub…

Links:

• Changelog
• MooTools 1.2.1 Download
• MooTools 1.2.1 Builder

What’s next?

We are going to keep going through all the tickets, and try to start fixing the bugs that have cropped up with some of the plugins. 1.2.2 might also see a few new features as we start preparing for some exciting changes and additions we have planned for 1.3.

MooTools 1.2 will be the last version of MooTools to support Safari 2 and Opera 9.5. These browsers have been advancing at a tremendous pace, and have a user base which updates regularly, so we don’t think this will be much of an issue when the time comes. Note that you don’t need to worry about this for quite some time yet because 1.3 is a long way off, but we just thought this was a good place to let everyone know.

So, what the heck is going on

Recently, a few users have been concerned that newcomers to MooTools might not easily be able to find their way around the MooTools community. As one of the developers, I kind of disagree, but there is one thing I think we all agree on; It probably wouldn’t hurt for us to communicate with everyone a little better. ;)

Along with the 1.2 release, we’ve changed up the site and moved away from SVN development. We’ve also removed Trac and the official forum in exchange for GitHub, Lighthouse, Google Groups, and other MooTools user maintained forum solutions. There is a ton of reasoning behind all the outsourcing and changes (including the simpler site, removal of the forums, switch to git development, etc) and if you like, you can read more about them…

• here
• here (sorry I can’t count!)
• and here

Is anyone actually writing any code?

Currently, we are working on getting the 1.2.1 release out as soon as possible. It focuses on bug fixes to some of the most important core components and documentation errata, (including a hack-less Class.js with returned Safari 2 support, sorry about that by the way!) Expect this release within the next few weeks.

Post 1.2.1, we will be simultaneously working on 1.2.x and 1.3. Any 1.2.x releases after 1.2.1 will focus on ‘core’ and ‘more’ bug fixes and maybe a few minor ‘more’ enhancements. As for 1.3, I don’t want to promise to much yet because we aren’t yet sure what will make it in, but just know that we have some really exciting things in store for this release! :D

I wish there was a book about MooTools

There is! Check out Aaron’s new book, MooTools Essentials. More information is available over at his MooTorial and here are some direct links to both the PDF and the Paper Back.

I bought the book early and I think it’s a really excellent resource for anyone who wants to learn the ins and outs of MooTools, and how to get the most out of it. PS: pages 94-95 are some of my favorites ;).

Conclusion? Sure, why not…

I encourage everyone to participate with and contribute to the community as much as possible. I really like the Google Group and think the wiki on GitHub has a lot of potential to be a real nice tool for users. Also check out and contribute to the unofficial forum. (Thanks for all your hard work over there guys). Here are some links:

• Google Group
• GitHub Wiki
• MooTools IRC Channel on Freenode
• Unofficial MooTools Forum

I must have missed something…

If you feel you need more information on something, or I wasn’t clear enough on something else, let me know in the comments, otherwise, please let me get back to work! (on both MooTools, and my real job. Yes, believe it or not, the developers actually need to have real jobs too!)

ciao for now…

We’re trying to assemble a comprehensive list of all our plugins. As part of this effort, we’re asking all plugin creators to send an email to plugins@mootools.net with the following information:

• Plugin Name
• Plugin URL
• Plugin Description (one line)
• Plugin author name and link (if applicable)

At this time, we’re only interested in collecting data on plugins which are compatible with the 1.2 release.

This is a temporary measure until we get a more interactive system in place.

Not only has the API been completely revamped, but there have been several significant changes to the site and the way the MooTools community interacts.

Why the Rush?

You may have noticed that the 1.2 release has come, quite literally, overnight. Over the past few months, we’ve come to realize that the 1.2 beta is even more stable than the “stable” 1.11 release. In fact, many developers (including some of us on the Moo team) have been using 1.2 in critical applications for some time now.

Users coming into #mootools asking for support have been unofficially told to by us to upgrade to 1.2 for months. Reluctant as we were to let ourselves call our work on 1.2 “complete”, the reality finally hit us that it was time to officially offer our release to the entire development community. We therefor decided to “just do it”, flipping the final switch and changing to the new version of the site before this blog post and some areas of the site were completely functional.

Where Have the 1.11 Docs and Demos Gone?

The 1.11 docs have been moved to http://docs111.mootools.net. Conversely, the 1.2 docs have been moved from http://docs12b.mootools.net to the main docs subdomain (http://docs.mootools.net). The same is true for demos.

• 1.11 Documentation
• 1.11 Demos
• 1.2 Documentation
• 1.2 Demos

1.2 is Totally New

Don’t let the version number fool you. 1.2 is not merely a minor revision of 1.11. As those of you who have been reading the blog will be aware, 1.2 has a completely updated API and is not compatible with 1.11 code. You can, however, utilize the compatibility layer that has been built to make the transition to 1.2 easier.

• Core Compatibility File
• Plugin Compatibility File

Since most of the changes between 1.2 and 1.11 have been documented in earlier posts to this blog, I won’t go into the details here.

Offsite Hosting of Version Management, Tickets, and Discussions

Because of the increasing popularity of this project of ours, we have been under an increasing amount of stress to keep the various parts of this site running in good order. You may have experienced downtime relative to MooTools recently. We understand that many developers utilize MooTools in critical components of their projects, and such downtime is completely unacceptable.

To solve these issues for the 1.2 release, we have moved our critical components offsite to the best provider of each component, granting MooTools users with the highest possible uptime of all areas of the site. A major benefit of this move is being able to completely reinvent the way we interact with our community of users (aka you guys!).

Git

Along with the 1.2 release comes our shift from Subversion to Git. Git is a huge step forward to our development model, allowing everyone who wants to contribute to MooTools the ability to create their very own fork. Each fork can then be merged into the main core as seen fit or used on its own as an alternate version of MooTools. This allows us to release faster, iterate to better versions and better handle the contributions of the community.

This allows would-be contributors to play in their own sandbox without worrying about whether or not their suggestions are appropriate. So get forking!

Please note that the Subversion repository will no longer keep up with changes to MooTools. You will have to check out the Git repository for that.

To keep the core lean and mean, we have created a separate repository for plugins, called “More”. Plugins are defined as specialty components which aren’t crucial to the core functionality of MooTools. This includes modules which have been part of the core distribution until now.

You’ll also notice that the download page has been split into two pages, one for Core and one for More. (Further repositories may be coming in the future if we can think of more rhyming names.)

GitHub

We’re using GitHub to host our new Git repositories. We now have one respository for Core and another for More. The folks over there have given us an extremely warm reception, and we are likewise very happy to have such a great service at our disposal.

Bug Tracking by Lighthouse

We have abandoned our Trac, which has been giving us problems over the past weeks, for Lighthouse. Lighthouse allows us to integrate our ticketing system with our new Github account and should provide everyone with a comparable experience to our previous system.

You can visit the new Lighthouse account here.

New MooTools User Group

As part of our offsite initiative, we have moved the community forum to Google, where it hopefully will not crash and die. The forums will be back shortly, but only as a read-only archive.

Join Us on IRC

While we’ve been partying in the IRC room for quite some time, the IRC link to #mootools on Freenode has been added to the main page of MooTools.net. If you have not visited us there before, please feel free to stop by to ask your questions or just hang out. We love chatting with new users.

New Faces

One last note is that we’ve added two new members to the MooTools production team, Jan Kassens and Thomas Aylott. Both of them have been working extremely hard for quite some time now to bring you a better framework, and we’re very happy to give them formal recognition.

Links In Case You Missed Them

Docs and Demos

• 1.11 Documentation
• 1.11 Demos
• 1.2 Documentation
• 1.2 Demos

Compatibility

• Core Compatibility File
• Plugin Compatibility File

Git Repositories

• Core Repository

• Plugin Repository

  THE SUBVERSION REPOSITORY WILL NO LONGER BE UPDATED.

Bug Tracking / Tickets

• MooTools at Lighthouse

Community Discussion

• MooTools Users at Google Groups
• #mootools on Freenode