MooTools 1.3 Cookbook
Over 110 highly effective recipes to turbo-charge the user interface of any web-enabled Internet application and web page
MooTroduction
MooTools was conceived by Valerio Proietti and copy written under MIT License in 2006. We send a great round of roaring applause to Valerio for creating the Moo.FX (My Object Oriented Effects) plugin for Prototype, a JavaScript abstraction library. That work gave life to an arguably more effects-oriented (and highly extensible) abstraction layer of its own: MooTools (My Object Oriented Tools).
Knowing our MooTools version
This recipe is an introduction to the different MooTools versions and how to be sure we are coding in the right version.
Getting ready
Not all are equal nor are backwards compatible!
The biggest switch in compatibility came between MooTools 1.1 and MooTools 1.2. This minor version change caused clamor in the community given the rather major changes included. In our experience, we find that 1.2 and 1.3 MooTool scripts play well together while 1.0 and 1.1 scripts tend to be agreeable as well. However, Moo’s popularity spiked with version 1.1, and well-used scripts written with 1.0, like MooTabs, were upgraded to 1.1 when released. The exact note in Google Libraries for the version difference between 1.1 and 1.2 reads:
Since 1.1 versions are not compatible with 1.2 versions, specifying version “1” will map to the latest 1.1 version (currently 1.1.2).
MooTools 1.1.1 has inline comments, which cause the uncompressed version to be about 180% larger than version 1.2.5 and 130% larger than the 1.3.0 release. When compressed, with YUI compression, 1.1 and 1.2 weigh in at about 65K while 1.3.0 with the CSS3 selectors is a modest 85K. In the code snippets, the compressed versions are denoted with a c.js file ending.
Two great additions in 1.3.0 that account for most of the difference in size from 1.2.5 are Slick.Parser and Slick.Finder. We may not need CSS3 parsing; so we may download the MooTools Core with only the particular class or classes we need. Browse http://mootools.net/core/ and pick and choose the classes needed for the project. We should note that the best practice is to download all modules during development and pare down to what is needed when taking an application into production.
When we are more concerned with functionality than we are with performance and have routines that require backwards compatibility with MooTools 1.1, we can download the 1.2.5 version with the 1.1 classes from the MooTools download page at http://mootools.net/download. The latest MooTools version as of authoring is 1.3.0. All scripts within this cookbook are built and tested using MooTools version 1.3.0 as hosted by Google Libraries.
How to do it…
This is the basic HTML framework within which all recipes will be launched.
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html >
<head>
<title>MooTools Recipes</title>
<meta http-equiv=”content-type” content=”text/html;charset=utf-8″/>
Note that the portion above is necessary but is not included in the other recipes to save space. Please do always include a DOCTYPE, and opening HTML, HEAD, TITLE, and META tag for the HTTP-EQUIV and CONTENT.
<script type=”text/javascript” src=”mootools-1.3.0.js”></script>
</head>
<body>
<noscript>Your Browser has JavaScript Disabled.
Please use industry best practices for coding
in JavaScript; letting users know they are missing
out is crucial!</noscript>
<script type=”text/javascript”>
// best practice: ALWAYS include a NOSCRIPT tag!
var mooversion = MooTools.version;
var msg = ‘version: ‘+mooversion;
document.write(msg);
// just for fun:
var question = ‘Use MooTools version
‘+msg+’?’;
var yes = ‘It is as you have requested!’;
var no = “Please change the mootools source attribute
in HTML->head->script.”;
// give ’em ham
alert((confirm(question)?yes:no));
</script>
</body>
</html>
How it works…
Inclusion of external libraries like MooTools is usually handled within the HEAD element of the HTML document. The NOSCRIPT tag will only be read by browsers that have their JavaScript disabled. The SCRIPT tag may be placed directly within the layout of the page.
There’s more…
Using the XHTML doctype (or any doctype for that matter) allows your HTML to validate, helps browsers parse your pages faster, and helps the Dynamic Object Model (DOM) behave consistently. When our HTML does not validate, our JavaScript errors will be more random and difficult to solve.
Many seasoned developers have settled upon a favorite doctype. This allows them to become familiar with the ad-nauseam of cross browser oddities associated with that particular doctype. To further delve into doctypes, quirksmode, and other HTML specification esoterica, the heavily trafficked http://www.quirksmode.org/css/quirksmode.html provides an easy-to-follow and complete discourse.
Finding MooTools documentation both new and old
Browsing http://mootools.net/docs/core will afford us the opportunity to use the version of our choice. The 1.2/1.3 demonstrations at the time of writing are expanding nicely. Tabs in the demonstrations at http://mootools.net/demos display each of the important elements of the demonstration.
(Move the mouse over the image to enlarge.)
MooTools had a major split at the minor revision number of 1.1. If working on a legacy project that still implements the deprecated MooTools version 1.1, take a shortcut to http://docs111.mootools.net.
Copying the demonstrations line-for-line, without studying them to see how they work, may afford our project the opportunity to become malicious code.
Using Google Library’s MooTools scripts
Let Google maintain the core files and provide the bandwidth to serve them.
Getting ready
Google is leading the way in helping MooTools developers save time in the arenas of development, maintenance, and hosting by working together with the MooTools developers to host and deliver compressed and uncompressed versions of MooTools to our website visitors. Hosting on their servers eliminates the resources required to host, bandwidth required to deliver, and developer time required to maintain the requested, fully patched, and up-to-date version.
Usually we link to a minor version of a library to prevent major version changes that could cause unexpected behavior in our production code.
Google API keys that are required in the documentation to use Google Library can be easily and quickly obtained at: http://code.google.com/apis/libraries/devguide.html#sign_up_for_an_api_key.
How to do it…
Once you have the API Key, use the script tag method to include MooTools. For more information on loading the JavaScript API see http://code.google.com/apis/libraries/devguide.html#load_the_javascript_api_and_ajax_search_module.
<!–script type=”text/javascript” src=”mootools-1.3.0.js”>
</script–>
<!–we’ve got ours commented out so that we can use
google’s here:–>
<script src=”https://www.google.com/jsapi?key=OUR-KEY-HERE”
type=”text/javascript”></script>
// the full src path is truncated for display here
<script src=”https://ajax.googleapis.com/…
/mootools-yui-compressed.js”
type=”text/javascript”></script>
</head>
<body>
<noscript>JavaScript is disabled.</noscript>
<script type=”text/javascript”>
var mooversion = MooTools.version;
var msg = ‘MooTools version: ‘+mooversion+’ from Google’;
// show the msg in two different ways (just because)
document.write(msg);
alert(msg);
</script>
Using google.load(), which is available to us when we include the Google Library API, we can make the inclusion code a bit more readable. See the line below that includes the string jsapi?key=. We replace OUR-KEY-HERE with our API key, which is tied to our domain name so Google can contact us if they detect a problem:
<!–script type=”text/javascript” src=”mootools-1.3.0.js”>
</script–>
<!–we’ve got ours commented out so that we can use google’s
here:–>
<script src=”https://www.google.com/jsapi?key=OUR-KEY-HERE”
type=”text/javascript”></script>
<script type=”text/javascript”>
google.load(“mootools”, “1.2.5”);
</script>
</head>
<body>
<noscript>JavaScript is disabled.</noscript>
<script type=”text/javascript”>
var mooversion = MooTools.version;
var msg = ‘MooTools version: ‘+mooversion+’ from Google’;
// show the msg in two different ways (just because)
document.write(msg);
alert(msg);
</script>
How it works…
There are several competing factors that go into the decision to use a direct load or dynamic load via google.load():
- Are we loading more than one library?
- Are our visitors using other sites that include this dynamic load?
- Can our page benefit from parallel loading?
- Do we need to provide a secure environment?
There’s more…
If we are only loading one library, a direct load or local load will almost assuredly benchmark faster than a dynamic load. However, this can be untrue when browser accelerator techniques, most specifically browser caching, come into play. If our web server is sending no-cache headers, then dynamic load, or even direct load, as opposed to a local load, will allow the browser to cache the Google code and reduce our page load time. If our page is making a number of requests to our web server, it may be possible to have the browser waiting on a response from the server. In this instance, parallel loading from another website can allow those requests that the browser can handle in parallel to continue during such a delay.
We need to also take a look at how secure websites function with non-secure, external includes.
Many of us are familiar with the errors that can occur when a secure website is loaded with an external (or internal) resource that is not provided via http. The browser can pop up an alert message that can be very concerning and lose the confidence of our visitors. Also, it is common to have some sort of negative indicator in the address bar or in the status bar that alerts visitors that not all resources on the page are secure.
Avoid mixing http and https resources; if using a secure site, opt for a local load of MooTools or use Google Library over HTTPS.
Great site you’ve got here.. It’s difficult to find high-quality writing
like yours these days. I truly appreciate individuals like you!
Take care!!