We recommend that all users upgrade to 1.4.4 as soon as possible.

Fixes

• #2160: Fx.Tween/Fx.Morph problem with ‘%’ unit
• #2175: IE Leak: Array.flatten
• #2178: IE doesn’t set value when creating element if css attributes are used
• #2241: Slick.finder index selector
• #2247: Element.get not reading custom attributes in IE7/8
• #2248: contains causes “Out of Stack Space” in IE
• #2252: Element.getParents doc clarification
• #2262: SVGAnimatedString causes Slick error
• #2266: Calling setOpacity with null does not remove the style
• #2275: Update Slick to 1.1.7

Known Issues

• #2184: IE9 on Windows Server throws exception; can’t continue
• #2194: Function#bind ES5 bug when bound function is called as part of a new expression
• #2199: Browser.version always returns the same for Android 2-4
• #2207: Fx.cancel() should clear animation so Fx.resume() will not continue it
• #2214: IE8 - Cannot inject into window.opener
• #2225: IE in-page memory leak when using removeChild
• #2236: IE8 tween/morph clip:rect breaks
• #2243: Memory leak with request class
• #2245: Element.getOffsets() is broken in iOS 4.3 if using -webkit-transform
• #2265: new Element(‘style’, {text: ”}) throws IE exception
• … and more

These issues will be fixed subsequently prior to release of the next maintenance release, 1.4.5.

Contribute

These fixes and improvements would not have happened if you didn’t submit an issue (ticket) to the MooTools Core Issues, or reporting your problems in the MooTools User Group. Send us your (MooTools) issues (or feature requests) so that your favorite JavaScript framework keeps getting better.

Get it!

• Download MooTools Core 1.4.4; Build MooTools Core 1.4.4
• Fork / clone MooTools Core 1.4.4 from GitHub, and build it yourself with Packager.
• Google CDN (will be updated soon)
• Browse the Documentation for Core & More.

Fixes

• #2109: IE7/8 getProperty returns functions
• #2110: Documentation: Request.JSON’s behaviour of onFailure
• #2117: Document conflicts between Array and Elements methods
• #2121: Missing Fx.options.frameSkip documentation.
• #2126: Re-add undocumented from argument to Element.fade
• #2127: Element.js memory leaks
• #2146: Add Element.NativeEvents to docs
• #2150: Add Fx.isPaused() method
• #2152: Packaging issue. Build header and Core.js yml header collide
• #2155: Add special note to Element.empty
• #2163: IE7 Crash with Mootools Core 1.4.2
• #2164: Cannot set numerical 0 values to form fields.
• #2169: Array#filter should store this[i] in a variable before calling the callback.
• #2170: propertychange on an input[type=radio] with this.checked fires standard onChange
• #2176: uid remnant which prevented proper cleaning of elements and their storage
• #2182: element.erase( ‘html’ ) sets content to text ‘undefined’

Known Issues

• #2129: < IE9 sets width/height attribute once, and doesn’t update on other loads
• #2130: Object.each doesn’t address IE DontEnum bugs like Object.extend and others
• #2160: Fx.Tween/Fx.Morph problem with ‘%’ unit
• #2168: Fixes 2129.
• #2175: IE Leak: Array.flatten
• #2178: IE doesn’t set value when creating element if css attributes are used
• #2183: Incorrect event.key from some keypress events in Firefox
• #2184: IE9 on Windows Server throws exception; can’t continue
• #2185: Fix #2184: IE9 on Windows Server throws exception; can’t continue
• #2188: Fixes #2178 - A input field should keep its value even when the type property is changed (in IE)
• #2189: Uncaught TypeError: Property ‘id’ of object # is not a function
• #2193: Element clone storage again
• #2194: Function#bind ES5 bug when bound function is called as part of a new expression
• #2196: it’s better for getStyle method always returns style value with px unit
• #2199: Browser.version always returns the same for Android 2-4
• … and more

These issues will be fixed subsequently prior to release of the next maintenance release, 1.4.4.

Contribute

These fixes and improvements would not have happened if you didn’t submit an issue (ticket) to the MooTools Core Issues, or reporting your problems in the MooTools User Group. Send us your (MooTools) issues (or feature requests) so that your favorite JavaScript framework keeps getting better.

Get it!

• Download MooTools Core 1.4.3; Build MooTools Core 1.4.3
• Fork / clone MooTools Core 1.4.3 from GitHub, and build it yourself with Packager.
• Google CDN (will be updated soon)
• Browse the Documentation for Core & More.

What is JxLib

JxLib is a JavaScript UI framework built on MooTools. It allows web developers and designers to quickly build user interfaces for their applications. JxLib is based on some sweet HMTL markup and strives to be fully CSS compliant. It is also a modular library allowing you to pick and choose from the available components as well as giving you the ability to override default behaviors and extend core classes.

All of this flexibility is, in large part, due to being built on MooTools. The library is heavily object-oriented with a huge number of classes inheriting from a single base. If you know how to use the MooTools class system you will quickly get up to speed on JxLib. In addition to being based on HTML and CSS, which provides an amazing amount of flexibility itself, the library’s architecture is based on a plugin system that allows additional functionality to be added to each component at the developer’s discretion.

A couple of quick examples

So, I wanted to show a couple of easy examples of what you can do with JxLib. There’s a ton of functionality built in and for more complete examples you can check out the examples page at jxlib.org. Here are 3 quick jsfiddles that you can play around with to get a feel of some of the functionality.

Example 1: Drop Down Menu Toolbar

This example shows a simple menu toolbar with cascading menus

Example 2 : Jx.Form and Form fields

This example shows off Jx.Form and a lot of the bundled fields you get out of the box.

Example 3: The New Jx.Container and Jx.LayoutManager classes

This one shows off some of the new work in JxLib 3.1.1. It creates the entire layout using a single javascript object. Check out the center panel’s tabs for a look at Jx.Editor and other components.

Experiences achieving compatibility with Core 1.4.2

I am happy to report that the conversion to Core 1.4.2 went relatively easily. The biggest conversion headache was when I originally worked on getting compatibility with 1.3.2 - that was a ton of work. We used many of the $ global methods ($defined, $H, $A were some of the big ones) and they were littered about the code base quite liberally. I really didn’t want to use the compatibility layer that the folks here at MooTools so graciously provided everyone because the download was big enough as it was. Hunting down all of those changes took the most time. In the process of doing so however I learned a few interesting tidbits:

First, it was best to replace $defined() with a check for undefined and null. for example:

if ($defined(some_variable)) {

became

if (some_variable !== undefined && some_variable !== null) {

I realize that the conversion docs state that checking undefined should be enough but when I tried that at first I got a LOT of weird errors. This change fixed them.

The other thing I discovered is that Object.each and Object.keys weren’t all that useful when the object you’re using them with was actually on the prototype of the class they were in. For example, in JxLib 2.0 we had this code:

processElements: function(template, classes) { 
    var keys = classes.getValues(); 
    elements = this.processTemplate(template, keys); 
    classes.each(function(value, key) { 
        if (key != 'elements' && elements.get(value)) { 
            this[key] = elements.get(value); 
        } 
    }, this); 
    return elements; 
}

It seems that those two functions use hasOwnProperty() which was causing the loop above to have 0 iterations because the classes variable was actually this.classes which was found on the prototype of the class. When converting to Core 1.3.2 (and subsequently 1.4.2) we had to use this:

processElements: function(template, classes) { 
    var keys = [], 
        values = []; 
    for (var key in classes){ 
        if (key !== undefined) { 
            values.push(classes[key]); 
            keys.push(key); 
        } 
    } 
    elements = this.processTemplate(template, values); 
    keys.each(function(key){ 
        if (key != 'elements' && elements[classes[key]] !== undefined && elements[classes[key]] !== null) { 
            this[key] =  elements[classes[key]]; 
        } 
    },this); 
    return elements; 
}

Once those were figured out, and we had full compatibility with 1.3.2, moving up to 1.4.x was pretty painless. For more info on what I learned during the conversion (some of it not MooTools or even javascript related) check out my blog post.

Get More information

You can get more information on JxLib at the following places:

• JxLib website
• JxLib github repository
• JxLib Google Group
• JxLib on Lighthouse
• Blog post on getting started with JxLib

If you have any questions or comments feel free to leave those below or in the Google group (linked above). Also, if you like what you’ve seen and read here please consider pitching in and helping to make JxLib even better. We have many plans for future releases but could always use a few extra hands.

Purpose

All well-written web sites / apps that are interactive have the same basic pattern:

Each page of a site or app you build is esoteric. It may have any combination of interactive elements, some of which interact with each other (for example, a form validation controller might interact with an ajax controller to prevent it sending a form that isn’t valid). Typically this “glue” code exists in a DOMReady statement. It says, get this form and instantiate that class with these options. This code is brittle; if you change either the DOM or the code the state breaks easily. It’s not reusable, it only works for a specific page state. It can easily get out of hand.

Behavior attempts to abstract that DOMReady code into something you only write once and use often. It’s fast and easily customized and extended. Instead of having a DOMReady block that, say, finds all the images on a page and turns them into a gallery, and another block that searches the page for all the links on the page and turns them into tool tips, Behavior does a single search for all the elements you’ve marked. Each element is passed through the filter it names, where a filter is a function (and perhaps some configuration) that you’ve named. Each of these functions takes that element, reads properties defined on it in a prescribed manner and invokes the appropriate UI component.

Why?

The nutshell is that instead of having a DOMReady function that finds the stuff in your DOM and sets up instances of classes and whatnot, you put the configuration in the HTML itself and write the code that calls new Foo(...) only once. Example:

So instead of this:

$$('form').each(function(form){
  new FormValidator(form, someOptions);
  new Form.Request(form, someOptions);
});
new Tips($$('.tip'));
$$('.accordion').each(function(container){
  new Accordion(container.getElements('.toggler'), container.getElements('.section'), someOptions);
});
//etc

You do this:

<form data-behavior="FormValidator FormRequest" data-formvalidator-options="{someOptions}">...</form>
<a data-behavior="Tip" title="I'm a tip!">blah</a>
<div data-behavior="Accordion" data-accordion-options="{someOptions}">...</div>

Think of it as delegation (as in event delegation) for class invocation. If you use DOMReady to do your setup and you want to swap out some HTML with AJAX, you need to reapply that startup selectively to only your components that you’re updating, which is often painful. Not with Behavior, you just apply the filters to the response and call it a day.

You do a lot less DOM selection; you only ever run $$('[data-behavior]') once (though some filters may run more selectors on themselves - like Accordion finding its togglers and sections).

DOMReady setup is always closely bound to the DOM anyway, but it’s also separated from it. If you change the DOM, you might break the JS that sets it up and you always have to keep it in sync. You almost can’t do that here because the DOM and its configuration is closely bound and in the same place.

Developers who maybe aren’t interested in writing components don’t need to wade into the JS to use it. This is a big deal if you’re working with a team you must support.

Behavior is designed for apps that are constantly updating the UI with new data from the server. It’s not an MVC replacement though. It’s designed for web development that uses HTML fragments not JSON APIs (though it can play nicely with them). If you destroy a node that has a widget initialized it’s easy to make sure that widget cleans itself up. The library also allows you to create enforcement to prevent misconfiguration and an API that makes it easy to read the values of the configuration. (More on that in a bit).

There are some other nifty things you get out of it; you get essentially free specs tests and benchmarks because the code to create both of them is in the Behavior filter. Here’s an example of what it takes to write a spec for a widget and ALSO the benchmark for it’s instantiation (this uses Behavior.SpecsHelpers.js).

Behavior.addFilterTest({
  filterName: 'OverText',
  desc: 'Creates an instance of OverText',
  content:  '<input data-behavior="OverText" title="test"/>',
  returns: OverText
});

This code above can be used to validate that the HTML fragment passed in does, in fact, create an OverText instance and it can also be used with Benchmark.js to see which of your filters are the most expensive.

Delegator

Included in the library is also a file called Delegator which is essentially the same thing except for events. For example, let’s say you have a predictable UI pattern of having a link that, when clicked, it hides a parent element. Rather than writing that code each time:

document.body.addEvent("click:a.hideParent", function(e, link){
  e.preventDefault();
  link.getParent().hide();
});

You register this pattern with Delegator and now you just do:

<a data-trigger="hideParent" data-hideparent-options ="{'target': '.someSelector'}">Hide Me!</a>

It provides essentially the same value as Behavior, but at event time. The above example is pretty straight forward so, you know, why bother, right? But consider how many of these little things you write to make a web app function. If you can create them once and configure them inline, you save yourself a lot of code.

BehaviorAPI

This stand-alone library facilitates reading values from element data- properties. Examples of the HTML expressions evaluated are as follows (all of the following produce the same output):

<tag data-behavior="Filter1 Filter2" data-filter1-options="{'opt1': 'foo', 'opt2': 'bar', 'selector': '.selector'}"> //prefered
<tag data-behavior="Filter1 Filter2" data-filter1-options="'opt1': 'foo', 'opt2': 'bar', 'selector': '.selector'"> //no braces on JSON
<tag data-behavior="Filter1 Filter2" data-filter1-options="{'opt1': 'foo', 'opt2': 'bar'}" data-filter1-selector=".selector">
<tag data-behavior="Filter1 Filter2" data-filter1-opt1='foo' data-filter1-opt2='false' data-filter1-selector=".selector">

The -options value is parsed as JSON first (it’s slightly more permissive in that you don’t have to wrap it in {} just for convenience). Values defined here are read as defined allowing you to express arrays, numbers, booleans, etc. Functions / callbacks are generally not used by Behavior.

If you attempt to read a value that isn’t defined in this options object, the property name is attempted to be read from the property directly (e.g. data-behaviorname-prop). This value is always a string unless you specify a type. If a type is specified the value is run through the JSON parser and validated against that type.

Even if you don’t want to use the whole Behavior suite, this library may be of use if you like the idea of including configuration inline. There’s a lot more in BehaviorAPI so it’s worth perusing the docs for it.

Documentation

• Behavior
• BehaviorAPI
• Element.Data

Stock Behaviors

Check out these resources of available Behavior Filters provided by the author:

• https://github.com/anutron/more-behaviors
• https://github.com/anutron/clientcide
• https://github.com/anutron/mootools-bootstrap

Demos

• MooTools Bootstrap Demos and Docs
• Clientcide (click on “demos” and check out the delegators and behaviors at the bottom of the left nav)

Notes

Below are some notes regarding the implementation. The documentation should probably be read first as it gives usage examples.

• Only one selector is ever run; adding 1,000 filters doesn’t affect performance.
• Nodes can have numerous filters.
• Nodes can have an arbitrary number of supported options for each filter (data-behaviorname-foo="bar").
• Nodes can define options as JSON (this is actually the preferred implementation - data-behaviorname-options="<your JSON>").
• Elements can be retired w/ custom destruction; cleaning up an element also cleans up all the children of that element that have had behaviors applied.
• Behaviors are only ever applied once to an element; if you call myBehavior.apply(document.body) a dozen times, the elements with filters will only have those filters applied once (can be forced to override and re-apply).
• Filters are instances of classes that are applied to any number of elements. They are named uniquely.
• Filters can be namespaced. Declare a filter called Foo.Bar and reference its options as data-foo-bar-options="...".
• There are “global” filters that are registered for all instances of behavior.
• Instance filters get precedence. This allows for libraries to provide filters (like http://github.com/anutron/more-behaviors) but for a specific instance to overwrite it without affecting the global state. (This pattern is in MooTools’ Form.Validator and works pretty well).

Limitations:

• Due to the DOM-searching for both creation and destruction, you can’t have behavior instances inside each other.

Downloading

You can find Behavior on github and also on Clientcide where you’ll also find a builder. That builder will also let you get the stock behaviors from Clientcide and the ones I’ve authored for MooTools More. If you want to get to the bootstrap builder, be sure to select “MooTools Bootstrap” in the top menu (or just clicketh hereth).

Fixes

• #2073: Reduced redundant call to onTimeout if async option is true.
• #2083: Fixes Element.clone in IE.
• #2085: All specs are green across.
• #2110: Element.erase('class') did not clear the class.
• #2113: button.set('type', 'button') is now fixed for webkit bug.
• #2116: Fixes Element.fade chain.
• #2118: $uid method is no longer exposed

Improvements

• #2089: Added support for native mouseenter and mouseleave.
• #2134: Deprecates the MooTools Core Specs repository in favor of including the specs in the Core repo. Due to ease of development.
• Series of new specs and refactoring of old specs. Specs are all passing and much faster.
• #2138: Native Element.fireEvent in IE is now accessible in via Element._fireEvent.

Known Issues

• Documentation fixes/additions for Element.NativeEvents, Fx, Request.JSON, and conflicts between Array and Elements methods.
• Object.each enumeration
• Possible leak with Element.adopt
• IE returns methods for some Element attributes.
• Element.Delegation problem with non-elements.

These issues will be fixed subsequently prior to release of the next maintenance release.

Get it!

• Download MooTools Core 1.4.2; Build MooTools Core 1.4.2
• Fork / clone MooTools Core 1.4.2 from GitHub, and build it yourself with Packager.
• Google CDN (will be updated soon)
• Browse the Documentation for Core & More.

Contribute

These fixes and improvements would not have happened if you didn’t submit an issue (ticket) to the MooTools Core Issues, or reporting your problems in the MooTools User Group. Send us your (MooTools) issues (or feature requests) so that your favorite JavaScript framework keeps getting better.

If you’re a plugin owner, you can subscribe by going to your plugin page and clicking ‘subscribe by email’ at the bottom.

Remember, if you find a bug in a plugin, you should always report it in that repository’s Github Issues.

As it stands, all comments will need to be moderated before they appear, just to make sure we don’t get trolled / spammed and we’re really looking forward to adding the ability to comment to the other parts of the website - particularly in documentation.

Thanks to Aaron for making this happen!

Upgrading from 1.4.0 should not cause any backward incompatibilities. We recommend all users to update to 1.4.1 as soon as possible.

Get it!

• Download MooTools Core 1.4.1; Build MooTools Core 1.4.1
• Fork / clone MooTools Core 1.4.1 from GitHub, and build it yourself with Packager.
• Google CDN (will be updated soon)
• Browse the Documentation for Core & More.

So all changes for 1.4.0:

• Move Delegation into Core.
• ECMAScript 5 compatibility fixes. Among them are Function.bind, Array.map and String.trim
• Deprecate Element.setOpacity() and Element.set('opacity'). Element.setStyle('opacity') is the only correct way now (the same applies for getters).
• Disable the 1.2 compat layer by default in the builder.
• Revamp Element.getProperty, Element.setProperty. Element.getProperty uses Slick.getAttribute now to share this code and save some bytes.
• IE7 doesn’t crash anymore when cloning an element twice.
• The Selectors documentation is back and updated for Slick.
• Update Slick to 1.1.6
• Unified change event behavior across browsers.
• Renamed Event to DOMEvent so it will not conflict with the native Event object.

Event Delegation

Event delegation is a common practice where an event listener is attached to a parent element to monitor its children rather than attach events to every single child element. It’s more efficient for dynamic content or highly interactive pages with a lot of DOM elements.

Example

var myElement = $('myElement');
var request = new Request({
    // other options
    onSuccess: function(text){
        myElement.set('html', text); // No need to attach more click events.
    }
});
// Adding the event, notice the :relay syntax with the selector that matches the target element inside of myElement.
// Every click on an anchor-tag inside of myElement executes this function.
myElement.addEvent('click:relay(a)', function(event, target){
    event.preventDefault();
    request.send({
        url: target.get('href')
    });
});

MooTools More

• Removed Delegation. It’s now in Core obviously.
• Added the length validator to Form.Validator
• Added the update method to HtmlTable which let you update rows
• Added ARIA accessibility to Tips.

If you’d like to know what exactly changed, checkout the compare view.

We would like to thank everybody who has contributed code, documentation fixes and ideas to make this release possible. Among them are arieh, Delapouite, madisvain, adamnbowen, mooyah, GCheung55, amadeus, rasmusfl0e, jasonwaters, realityking, Nico-B, mcfedr, donatj, csuwldcat, ibolmo, cpojer, kamicane, timwienk, fakedarren, anutron, subtlegradient and myself arian.

Bugs

Thanks to GitHub contributing is easier than ever. It’s very easy to fix them or to report them, especially since we moved to GitHub for our issues. Bugs can reported on the MooTools Core Bug Tracker and for MooTools More you can go to the More Bug Tracker.

If you have any questions, either about how to do something or about contributing you can ask, or something to share, just join the MooTools Mailing list or IRC (#mootools on freenode.net). We have an office hour each Tuesday but you can hang out there whenever you want.

Get it!

• Download MooTools Core 1.4.0; Build MooTools Core 1.4.0
• Build MooTools More 1.4.0.1
• Fork / clone MooTools 1.4.0 from GitHub, and build it yourself with Packager.
• Google CDN (which should be updated soon)
• Browse the Documentation for Core & More.

Especially the additions for milestones and assignees were important for us. With this in place GitHub issues can finally replace Lighthouse.

The main advantages are:

• Everything at one place, one login
• Easier to follow MooTools
• Similar to pull requests

A disadvantage is that most of the current issues are in Lighthouse. Darren did an awesome job going through a lot of them but there are still some open or not fixed. A proposed option was to move all tickets to GithHub, but we decided to try to address as many as we can and just move on to GitHub.

Now every MooTools project has its issues on GitHub:

• MooTools Core
• MooTools More
• Slick
• Demos

So if you know anything about any of the issues at GitHub or some old Tickets at Lighthouse, comments and fixes are highly appreciated!

This recap includes:

• Mentions
• Answers to: Where do you guys think MooTools can improve?
• Sneak Peak to Improved Docs
• Agenda for July 19th Dev Hour

Mentions

Sean McArthur (seanmonstar) is working on a MooTools-based MVC Framework called Shipyard. The framework is made for working on the browser, but it can run on Node.JS. He’s been testing Shipyard and we mentioned that he should try the mootools-runner which runs the specs for Core and More. The Runner can be run via the browser, node.js, or CLI (via JsTestDriver). It’s lightning fast and easy to contribute to. All specs are written in Jasmine and mocked by Sinon.JS.

Another user talked to us that he’s in high school in Colorado, and that he’s trying to convert his church to use MooTools instead of jQuery. We recommended that he should try to ween the church off of jQuery by using Ryan Florence’s moo4q, a helper to bring Object Oriented programming to jQuery.

Another user had asked if anyone had worked on HTML5’s pushState, and we’ve pointed him to MooTools’ own Christoph Pojer’s PowerTools. In particular, if you’re looking for a history plugin I highly recommend mootools-history.

Questionaire

Last week we asked the channel: Where do you guys think MooTools can improve? We’re always glad to hear from our users and here are a few notable mentions from last week’s questionaire.

Lighter weight: alpha123 had mentioned that there are some utility methods that he never uses and could go. Likewise, xandros pointed out that between 1.2 and 1.3 the same build with specific dependencies had grown in size. I couldn’t agree more. We’ve always been careful with the size of your builds by giving you the power to build the smallest build possible with the online web builder or with Packager. Undoubtedly the 1.y.x branch has grown in size due to maturity and contributions from the team and our users. I’d like to personally try to arrange a “Dependency Cops” team that tries to monitor and reduce the baggage in some of the dependencies. We’d like for you to help us, though. In spare time (if any) read the source code and try to find sections of code that can be moved or refactored into its own file. This way we can reduce the bytes in the dependency chain. Send us a pull request.

Marketing and Evangelism: jazzman had mentioned that MooTools marketing and evangelism could definitely improve. Historically, MooTools core developers have shied away from marketing MooTools as a product. We’ve done this to reduce distractions and instead we’d focus strictly on the code. (If you build it, they will come.) I think that as a team we’re shifting our beliefs towards being more vocal and open about our philosophies and code. We love MooTools and think that others would be surprised with MooTools and how easy our principles help to code better. Not just for MooTools, but JavaScript. And so, we are warming up to the idea to be proactive with spreading the Moo. And so should you. Just be courteous and qualitative. MooTools is not infallible and it’s not always the best tool for the job. We need responsible and honest people whose interests lies in improving code, coming to a solution, and moving forward.

More UI Goodness: UI components have been around since the beginning of MooTools (see: Accordion madness). We understand that many of you are looking for the team to build a UI framework, and we’d like to serve your needs. At the moment, however, we have bigger fish to fry (MooTools 2.0). Instead, please see this blog post for some mentions of UI libraries that are built on top of MooTools, or to use other libraries/frameworks (we’re all friends here). If you’re interested in championing this cause, then the best way to get an official (sanctioned) MooTools repo is to: do it™ and to keep us in the loop (ask us to review your commits).

More sourced content: We’d like to work on more screencasts, slideshows, presentations, demonstrations and other content that would help you understand MooTools as well as show it off to your friends, nemesis, or colleagues. We understand that it’s hard to convince your team members or employer to adopt MooTools. We are working to improve this area, but we need your help. Leave us a comment on how we can help you understand or overcome hurdles when speaking with people. I’ve had a few ideas: providing you with introduction presentations that you can give to your peers, for example.

Any other areas that you think we need to improve?

Sneak Peak to Improved Docs

Darren Waddell has been working on your suggestions from past Office (Dev) Hours. In this sneak preview: each method has its own page and its own comment section (ala PHP). We’ve only shared this sneak peak with a few people and we’re already seeing contribution. To see the improved docs you’ll have to create a new cookie newdocs. Confused? Here’s the instructions on how to use the new docs:

1. Go to the Core Docs.
2. Copy and paste this: javascript:Cookie.write('newdocs', true, {path: '/'}) into your address bar (or into a console).
3. Refresh the page.

If you did the above correctly, you should see that the Element Docs have been split into individual pages.

Darren has done a great job so far. If you’d like to help please leave your suggestions or fork the mootools-docs repository.

Agenda for July 19th Dev Hour

• Features and Roadmap of 1.4.0. Believe it or not, we’re still working on the release of 1.4.x. Word has it that Delegation will finally move to Core. Plus a bunch of bug fixes.
• Improved Docs Feedback and Work. We’d like for you to join us to talk about the improvements that we’re making on the documentation.
• Bug Hunting in Lighthouse Tickets and Github Issues. To release 1.4 we’re going to need to fix a lot of bugs and to have our users report any issues. Please report your issues to Github, as Lighthouse is now deprecated (blog post coming soon).
• Open Forum. As always, we’d love to meet you and talk about all things Moo.

Next Office Hour

Remember that we’re having the next office hour this:

Tuesday, July 19th at

05:01 - Honolulu (Hast UTC-10)
08:01 - San Francisco (PDT UTC-7)
10:01 - Chicago (CDT UTC-5)
11:01 - New York (EDT UTC-4)
12:01 - Rio de Janeiro (BRT UTC-3)
16:01 - London (BST UTC+1)
17:01 - Vienna (CEST UTC+2)
18:01 - Kyiv (EEST UTC+3)
20:31 - Mumbai (IST UTC+5:30)
23:01 - Hong Kong (HKT UTC+8)
00:01 - Tokyo (JST UTC+9)
01:01 - Sydney (EST UTC+10)
03:01 - Auckland (NZST UTC+12)

We’ll be in the #mootools freenode.net channel.

Guidelines

We did very well last week in following the guidelines. I’ve included them in this post as a reminder.

1. Please use jsfiddle.net and keep your code with minimal boilerplate — get to the essence of your question
2. Stay on topic. Let’s keep the chat around MooTools and how it interacts with your code and the rest of the JavaScript ecosystem.
3. Be courteous and helpful with others. We are not guaranteeing that all of us will give you our undivided attention during the hour (we are also working!). If you can answer a question (as best as you can) it will really be helpful.
4. Sharing is caring. Share the room, but also share the event. Post to twitter, Facebook, your blog, and tell your parents. We want to foster growth in our community. This is the chance to participate and to help.

Tips

Use this button to add the open office hour to your Google Calendar. You’ll need to setup the event so that it repeats weekly.

If you don’t have an IRC client you can use http://webchat.freenode.net/.

This recap includes:

• Compare 1.3.x and Experimental 2.y.x Code Diffs
• Things to Come (Agenda’ed Office Hour, Dedicated “Hackathon” Office Hours)

Last week we had a small conversation of the experimental branch that Valerio has for MooTools 2.0. The conversation covered most of the comments in last week’s post comments. Instead of going over them again, please take a look at last week’s post.

Compare 1.3.x and Experimental 2.y.x Code Diffs

Like I had promised last week, I did want to start a repository for helping you understand what are the main differences (in code) between 1.3.x and the experimental 2.y.x. Last week the mootools-1-vs-2 repository to do just that. You can use Github’s awesome Compare View to view the differences between 1.3.x and 2.y.x (Valerio’s experimental branch).

The files included in the repo are meant to compare Core code, Plugin code, and Application code:

Core Code

• Request.js is from the MooTools Core/Request.

Plugin Code

• Database.js (by Daniel Buchner). You can find the original Database.js in the repo as well as in his csuwldcat/mootools-htmlx.

• ScrollSpy.js (by David Walsh). You can find the original ScrollSpy.js in the MooTools Forge.

Application Code

• Examples/001.js and Examples/002.js are examples from the Request.js documentation.

Caveats

The examples are not all encompassing of user behavior and usage. I did select the scripts, but I tried to be fair. You can fork the repository and add your files to the 1.3.x branch (the base branch) and send me a pull request and I’ll try to port your code. Please be considerate, and send me at most one file with recommended maximum of 500 lines.

The code will change as 2.0 is further defined. The 2.0 API is not final. Valerio is kicking butt everyday on his experimental branch. This compare 1.3.x vs. 2.y.x repo. is meant to assuage some of the concerns from the previous blog post about Valerio’s experimental 2.0 branch.

This repo is not a definitive guide to 2.0. We’re still working on that definitive guide for 2.0, but since the API is not strictly defined it’s premature to give you this. For now, leave your comments or join us tomorrow with your questions.

The repo doesn’t show Host.Install. The intention of the repo. is to show the default behavior of 2.0. I’m likely to create another branch and call it 2.y.x-installed so that you’ll see the differences between 1.3.x and 2.0.x with native extensions installed.

Things to Come.

Agenda for the Office Hours

We were asked that Office Hours should have an agenda so that we can have a more directed conversation. I didn’t have a chance to inquire the team for items, but we should have some items for next week.

Any suggestions? Leave a comment below.

Mini Hackathons or “Dedicated” Office Hours

Similar to the above, it’s been suggested by Darren Wadell and Arian Stolwijk that we could dedicated actionable work hours. We could have demos office hour, documentation, bugfix or test office hours for example.

What do you think? Would you participate?

Next Office Hour

Remember that we’re having the next office hour this:

Tuesday, July 12th at

05:01 - Honolulu (Hast UTC-10)
08:01 - San Francisco (PDT UTC-7)
10:01 - Chicago (CDT UTC-5)
11:01 - New York (EDT UTC-4)
12:01 - Rio de Janeiro (BRT UTC-3)
16:01 - London (BST UTC+1)
17:01 - Vienna (CEST UTC+2)
20:31 - Mumbai (IST UTC+5:30)
23:01 - Hong Kong (HKT UTC+8)
00:01 - Tokyo (JST UTC+9)
01:01 - Sydney (EST UTC+10)
03:01 - Auckland (NZST UTC+12)

We’ll be in the #mootools freenode.net channel.

Guidelines

We did very well last week in following the guidelines. I’ve included them in this post as a reminder.

1. Please use jsfiddle.net and keep your code with minimal boilerplate — get to the essence of your question
2. Stay on topic. Let’s keep the chat around MooTools and how it interacts with your code and the rest of the JavaScript ecosystem.
3. Be courteous and helpful with others. We are not guaranteeing that all of us will give you our undivided attention during the hour (we are also working!). If you can answer a question (as best as you can) it will really be helpful.
4. Sharing is caring. Share the room, but also share the event. Post to twitter, Facebook, your blog, and tell your parents. We want to foster growth in our community. This is the chance to participate and to help.

Tips

Use this button to add the open office hour to your Google Calendar. You’ll need to setup the event so that it repeats weekly.

If you don’t have an IRC client you can use http://webchat.freenode.net/.

Recap

Last week’s office hour was dominated by the experimental define-2 branch by Valerio. This branch has the experimental support of Asynchronous Module Definition (AMD) and also has the proposed direction of MooTools 2.0 as mentioned in the previous blog post.

From the discussion in last week’s office hour, it seemed that there was confusion on the implications of adopting Valerio’s 2.0 branch. In particular there were concerns for: compatibility, native extensions (and minimum ES5 polyfills), chainability, and style.

At first, 2.0 will likely not be compatible with 1.3 without a builder and an upgrade script. Since we’ve yet to cross this road, please be vigilant of the changes and discussion that are underway. As always, rest assured that we would like to make your transition into 2.0 as easy and immediate as possible.

Without a dedicated blog post, I’d like to recap that there is a divide between the community and even the MooTools developers about the possible decision to not extend native objects (e.g. Array, Number, String, …) by default. One side of the argument is that this is a 180 degree shift in MooTools style and philosophy and that it ruins competitive differentiation (a marketing term). On the other side of the argument is that this is necessary to stay relevant in the discussion, that we’ve cornered ourselves between a rock and a hard place and that we just need to be better. Valerio had even quoted Steve Jobs as a perfect explanation on his position.

Instead of going further and making points for either argument, it’d be more appropriate if we make a definitive post on the matter.

Next Office Hour

The discussion is still not done. If you’d like to give us your $0.02 on the matter, we welcome your thoughts and concerns. If you’d like to contribute to the 2.0 Wish List, add your suggestion or talk to us on IRC. Remember that we’re having the next office hour this:

Tuesday, July 5th at

05:01 - Honolulu (Hast UTC-10)
08:01 - San Francisco (PDT UTC-7)
10:01 - Chicago (CDT UTC-5)
11:01 - New York (EDT UTC-4)
12:01 - Rio de Janeiro (BRT UTC-3)
16:01 - London (BST UTC+1)
17:01 - Vienna (CEST UTC+2)
20:31 - Mumbai (IST UTC+5:30)
23:01 - Hong Kong (HKT UTC+8)
00:01 - Tokyo (JST UTC+9)
01:01 - Sydney (EST UTC+10)
03:01 - Auckland (NZST UTC+12)

Add it to your Google Calendar.

We’ll be in the #mootools freenode.net channel.

Guidelines

We did very well last week in following the guidelines. I’ve included them in this post as a reminder.

1. Please use jsfiddle.net and keep your code with minimal boilerplate — get to the essence of your question
2. Stay on topic. Let’s keep the chat around MooTools and how it interacts with your code and the rest of the JavaScript ecosystem.
3. Be courteous and helpful with others. We are not guaranteeing that all of us will give you our undivided attention during the hour (we are also working!). If you can answer a question (as best as you can) it will really be helpful.
4. Sharing is caring. Share the room, but also share the event. Post to twitter, Facebook, your blog, and tell your parents. We want to foster growth in our community. This is the chance to participate and to help.

Tips

Use this button to add the open office hour to your Google Calendar. You’ll need to setup the event so that it repeats weekly.

If you don’t have an IRC client you can use http://webchat.freenode.net/.

Topics Covered

• MooTools 2.0 Community “Wish List”
• MooTools Documentation
• Flex Box Model
• Require.JS and Namespacing
• MooTools Roadmap
• MooTools Feature: Accessors
• Model Change Events
• MooTools 2.0 Site
• MooTools UI and Mobile
• Event Delegation in Core
• Github Issues

MooTools 2.0 Community “Wish List”

We created a document and shared with the IRC channel a “wish list” to add requests of what MooTools 2.0 should include. You can find the wish list here. Please add your own requests. Periodically we’ll check the list and approve items for 2.0.

MooTools Documentation

We talked about our efforts to improve the documentation. We were suggested in the channel to improve the argument list in the docs and include inherited properties and methods (plus link to the parent class).

We also want to make the experience more viral and social and we’d like to include social plugins (Facebook and Twitter). A comments section akin to PHP’s plus heavy moderation to have quality comments and shared experiences.

Analytics will also play a major role as we’d like to improve feedback. We’d like to know which methods and classes are most viewed, liked, and commented. Likewise, we want to make it easier for you to find what you’re looking for. Better SEO as well as navigation and search inside of the docs.

While you are in the documentation, we are also adding inlined jsfiddle so that you can run the examples/demos and modify them on the fly. This also means that you can contribute your own examples/demos.

Of course, the above is a lot of work and we welcome your participation. Darren Waddell has stepped up and already started working on this. Take a look at his repository (fakedarren/mootools-docs) and please fork. User, kpobococ, is already working with Darren thanks to the office hour.

Flex box module

A user had a question about the “wrapping” of the UI so that it extends to the complete window. It’s not built-in to MooTools, but we gave him a few suggestions on how to accomplish this. Ryan Florence mentioned his mootools-wallpaper and a jsfiddle example.

AMD, requirejs, namespacing

First, some context. require.js is a “file and module loader” which implements the Asynchronous Module Definition (AMD) CommonJS specification. This means that you can define modules and require (load) them only if they’re necessary. The philosophy is aligned to ours. We’ve never wanted our users to download the complete repository and load it blindly into a page. We’ve supported modularity, and speed, since day 1. Rest assured that MooTools 2.0 will be require.js ready out of the box.

Namespacing, is a loaded term. It may mean to “sandbox” MooTools so that it doesn’t mess with prototypes. Namespacing may also mean that you can apply, or install, methods into any given object. We’ll make a separate blog post about this, but it’s time to let the cat out of the bag.

We would like for MooTools 2.0 to play nice with everyone. This is a huge departure from 1.x days, but we’d like to position MooTools 2.0 so that you can drop it in any environment (that JavaScript can be run) and it will Just Work™.

Valerio Proietti has started to work on this in his own define-2 branch and we’re looking to you for feedback and opinions. Please fork and send feedback. Now is the time to make your voice heard. Once we release 2.0, there’s no going back.

MooTools Roadmap

And this brings us to the roadmap. Again, well deserving of its own blog post. Here’s the official word from Valerio, himself. We’re going straight to 2.0. There’s no date, yet, on when this will happen but a lot of work and time is being put to get it out the door.

This would be the time, for you to volunteer your time.

Oh and don’t run around frantically. 1.3.x will continued being developed but released as bug fixes and any improvements provided by the community or downgraded from 2.0.

MooTools 2.0 Feature: Accessor

Still in its infancy this pattern is very powerful. It’s deserving of its own blog post, but here’s the summary: with this pattern you can define and lookup functions and properties that are usually Objects now, like Class.Mutators or Element.Properties. Besides simple lookup, it can also do a match so a ‘protected’ Class Mutator can be defined so a Class method can be defined as ’protected foo’: function(){ so that the method cannot be run outside of the class. Have a look at the source.

Model Change Events

Someone had asked to support events for when properties change in the form of change:foo. It’s doubtful we’ll have this, but developer, verylastminute, has already worked on something that might serve in the mean time: ElementSpy.

MooTools 2.0 Site

As you might have expected, there will be a new site for the launch of 2.0. We’re not yet in implementation stage, but we have screenshot of what it might look like. If you’d like to get involved in the design (for some street cred) join us in the IRC channel to get in touch with Nathan Querido, from QueridoDesign, since he’s leading that project.

MooTools UI and Mobile

There’s a strong request for an official UI and Mobile projects. Although we are not promising that we will get around to the UI and Mobile prior to 2.0 release, we do agree on having them. For now we’re supporting projects that fill this need.

For the mobile, we’re interested in jpdery/moobile-core and cpojer/mootools-mobile. Add your projects in the comment section.

For UI we have our own ART project which is almost ready to be released. Missing documentation and testing. There’s also projects we’re interested in: inviz/lsd, anutron/behavior, JxLib, and sixtyseconds/mootools-interface. Add your projects in the comment section.

Event Delegation in Core

We’re also promising that Event Delegation will be in Core before 2.0 is out the door. Still unknown if the API will change between 1.3.x and 2.0, but let’s revel in the news!

Github Issues

Again one of those, “deserving of its own blog post” we’re moving from Lighthouse Tickets to Github Issues. This means that we will accept any new issues in Github and discourage the use of Lighthouse. We will disable Lighthouse after we’ve migrated.

Next Office Hour

As you’re now aware, the MooTools Office Hours are very fun and informative. Remember that we’re having another this:

Tuesday, June 28th at

05:01 - Honolulu (Hast UTC-10)
08:01 - San Francisco (PDT UTC-7)
10:01 - Chicago (CDT UTC-5)
11:01 - New York (EDT UTC-4)
12:01 - Rio de Janeiro (BRT UTC-3)
16:01 - London (BST UTC+1)
17:01 - Vienna (CEST UTC+2)
20:31 - Mumbai (IST UTC+5:30)
23:01 - Hong Kong (HKT UTC+8)
00:01 - Tokyo (JST UTC+9)
01:01 - Sydney (EST UTC+10)
03:01 - Auckland (NZST UTC+12)

Add it to your Google Calendar.

We’ll be in the #mootools freenode.net channel.

Guidelines

We did very well last week in following the guidelines. I’ve included them in this post as a reminder.

1. Please use jsfiddle.net and keep your code with minimal boilerplate — get to the essence of your question
2. Stay on topic. Let’s keep the chat around MooTools and how it interacts with your code and the rest of the JavaScript ecosystem.
3. Be courteous and helpful with others. We are not guaranteeing that all of us will give you our undivided attention during the hour (we are also working!). If you can answer a question (as best as you can) it will really be helpful.
4. Sharing is caring. Share the room, but also share the event. Post to twitter, Facebook, your blog, and tell your parents. We want to foster growth in our community. This is the chance to participate and to help.

Tips

Use this button to add the open office hour to your Google Calendar. You’ll need to setup the event so that it repeats weekly.

If you don’t have an IRC client you can use http://webchat.freenode.net/.

This is a reminder that tomorrow (June 21st) we’re having another office hour and you’re cordially invited to join us.

Unlike last week, this week we’ll have a couple of questions ready to steer the conversation. This week we’ll talk about MooTools 2.0 and what you guys need to love MooTools even more. We’ll be taking names down as well, for those that would like to contribute.

Keep reading to learn the details.

When & Where

If you’re familiar with last week’s office hour, you probably realize that I made a boo boo with the offset in different timezones. This is now fixed thanks to EveryTimeZone. Here’s a complete list of timezones just so that we’re all on the same page.

Tuesday, June 21st at

05:01 - Honolulu (Hast UTC-10)
08:01 - San Francisco (PDT UTC-7)
10:01 - Chicago (CDT UTC-5)
11:01 - New York (EDT UTC-4)
12:01 - Rio de Janeiro (BRT UTC-3)
16:01 - London (BST UTC+1)
17:01 - Vienna (CEST UTC+2)
20:31 - Mumbai (IST UTC+5:30)
23:01 - Hong Kong (HKT UTC+8)
00:01 - Tokyo (JST UTC+9)
01:01 - Sydney (EST UTC+10)
03:01 - Auckland (NZST UTC+12)

Add it to your Google Calendar.

We’ll be in the #mootools freenode.net channel.

Guidelines

We did very well last week in following the guidelines. I’ve included them in this post as a reminder.

1. Please use jsfiddle.net and keep your code with minimal boilerplate — get to the essence of your question
2. Stay on topic. Let’s keep the chat around MooTools and how it interacts with your code and the rest of the JavaScript ecosystem.
3. Be courteous and helpful with others. We are not guaranteeing that all of us will give you our undivided attention during the hour (we are also working!). If you can answer a question (as best as you can) it will really be helpful.
4. Sharing is caring. Share the room, but also share the event. Post to twitter, Facebook, your blog, and tell your parents. We want to foster growth in our community. This is the chance to participate and to help.

Tips

Use this button to add the open office hour to your Google Calendar. You’ll need to setup the event so that it repeats weekly.

If you don’t have an IRC client you can use http://webchat.freenode.net/.

In Closing

Remember that we’re doing this because we love to meet our community leaders. Bring your colleagues or even your boss if you have questions that you’re concerned with or would like solutions for.

Last week we had a lot of fun bringing a lot of MooTools developers together which spurred some development. Looking forward to tomorrow for a great hour.

Cheers.

We’re following the footsteps of many successful office hours from other Open Source projects (Android, Mongo DB, Google App Engine, and Node.JS) because we think it’s the best way to help, meet, and listen to our community.

In fact, without IRC I wouldn’t have become a MooTools developer in the first place. Like many of the other MooTools developers. Maybe you will too.

When

We’re going to start with a single weekly meeting on Tuesday’s at 5pm - 6pm (CEST GMT) (11am - 12pm EDT EST). We chose this time since it best fits our schedule, but depending on response and returns (more development, more team members, etc.) we can have a dedicated time for Western and for Eastern hemispheres.

Our first meeting is next Tuesday, June 14th at 11am EDT EST (5pm CEST GMT).

Guidelines

With any endeavor there are some ground rules for efficacy.

1. Please use jsfiddle.net and keep your code with minimal boilerplate — get to the essence of your question
2. Stay on topic. Let’s keep the chat around MooTools and how it interacts with your code and the rest of the JavaScript ecosystem.
3. Be courteous and helpful with others. We are not guaranteeing that all of us will give you our undivided attention during the hour (we are also working!). If you can answer a question (as best as you can) it will really be helpful.
4. Sharing is caring. Share the room, but also share the event. Post to twitter, Facebook, your blog, and tell your parents. We want to foster growth in our community. This is the chance to participate and to help.

Tips

Use this button to add the open office hour to your Google Calendar. You’ll need to setup the event so that it repeats weekly.

If you don’t have an IRC client you can use http://webchat.freenode.net/.

In Closing

I expect this will be a lot of fun and a great learning experience to find out how our community has been prospering and using MooTools. Hope to see you in the IRC channel!