MooTools Core 1.3.2 and More 1.3.2.1

Written By Arian Stolwijk, on Thursday, April 28th 2011, 3:23pm

Today we announce the simultaneous release of MooTools Core 1.3.2 and More 1.3.2.1. This is mostly a bugfix release and does not contain many new features. The most important fix is within our selector engine, Slick, which failed in some cases where the selectors began with an operator (ex. ~div).

A new component has been added to MooTools More: Table. Table was slated to be added in MooTools Core 2.0, but we’re making it available in MooTools More now. Table is similar to the JavaScript object literal, but where an object can only have a scalar value (string or number) as a key, Table can have any value as a key. Where the order of values in an object is not static like an array (by specification, usually browsers keep the order which they are defined), the values in Table will have a static order. These advantages come with a performance cost, where an object value is a direct look-up, Table uses indexOf which is less efficient, so use with care.

Notable changes in MooTools Core include:

  • Fixed Slick bug with ~div-like selectors
  • Fixed MooTools in the Node.js environment
  • Fixed an exception in DOMReady in Chrome when the page with MooTools was in an IFrame
  • Fixed setOpacity for very small numbers in IE
  • Fixed an exception in FireFox 4 when MooTools tried to overwrite document.head
  • Added the possibility to create elements with boolean values with an selector, e.g. new Element('input[checked]');

MooTools More:

  • Rewritten Element.Position which solved some issues
  • Added Table, as described above
  • Ironed out some Event Delegation issues
  • Additional fixes can be found at the Lighthouse for 1.3.2.1

Get it!

14 Responses to “MooTools Core 1.3.2 and More 1.3.2.1”

  1. Rudie says:

    Why doesn’t Mootools use Sizzle? jQuery uses Sizzle and is always much faster. Even the Slick test proves that. Total 2 for Sizzle and total 11 for Slick.

    Does Mootools use document.querySelector(All) when avaiable?

  2. doubleTap says:

    What was broken in node.js that was fixed with this release?

  3. CristianTheEvil says:

    I Got it!

    Thanks

  4. cpojer says:

    @doubleTap we introduced a change in 1.3.1 in which we used the file-wide “this” as global variable. In modules in nodeJS ‘this’ refers to the module and not to the global variable. We have reverted this change for now.

  5. leeeb says:

    I just went looking for the node.js changes, there’s no lighthouse ticket for it but this seems to be the commit https://github.com/mootools/mootools-core/commit/8521f484fff56bafe48bbaed5ff3dced760d382. The problem seems to be the different scope of “this” between conventional browser based scripts and commonjs environments such as node.js.

  6. cpojer says:
  7. cpojer says:

    @Rudie a couple of years ago we made this statement about Sizzle: http://mootools.net/blog/2008/12/04/sizzle/

    Slick is not only about speed but mostly about accuracy. It doesn’t matter how fast your engine is, if at any time it returns wrong results. You must be able to rely on your selector engine to be correct at all times and this is what we focus on. Also note that Slick is optimized for all selectors and not just a couple of selectors that we assume you use often.

    Slick does use qSA if available and appropriate.

    SlickSpeed came from a time when selector engines took several hundred ms to match certain elements. As you can see, the difference in all selectors is only a few ms. Microseconds. And this difference probably comes from rounding errors. All selector engines are fast enough and if you experience slowdowns because of the used selector engine you either have inappropriate code (no caching etc.) or a huuuuge document. Please don’t use SlickSpeed any more to compare selector engines. It helped improve engines a few years ago, but the aim SlickSpeed used to have is fulfilled and the project is finished. As said, Slick is about accuracy first, speed second.

    Please note that MooTools 2.0 will likely allow to switch out the Finder part of Slick with any other selector engine (Slick.Finder.js, Slick.Parser.js will still be required). I don’t promise it though. I coined it a couple of days ago and we have a possible implementation.

  8. dreadcast says:

    I’ll try this release with v8cgi tomorrow… I hope it’ll work, unlike 1.3.1 which seems to be uncompatible dued to “Function”.

    God I miss Jaxer which worked altogether with mootools (Not only Class, but Element, Date, Array, Hash, Window or Event as well).

    Is there any way to get Element back into the server build ?

  9. Rolf says:

    Thumbs up to the team

  10. dreadcast says:

    About V8 (and probably nodejs) : it works !

    Object (and his lil’ bro Hash), Date, Locale work as well, but in Date.js, this line :

    var Date = this.Date = {};

    has to be commented out (I don’t know why, I haven’t dug deep enough).

    Unfortunately, since there’s no window or document object, it looks like Element is going to be a little bit more complicated to implement.

  11. gonchuki says:

    @Rudie: there’s also the fact that Sizzle is not fully CSS3-compliant, so stuff like :nth-last-child and :nth-last-of-type will give a false sense of support in Sizzle in browsers with qSA and fail terribly on older browsers. Slick implements the whole CSS3 spec from the beginning, as cpojer said it’s more about accuracy than speed.

  12. cainrus says:

    Great. I like to watch for new mootools releases. You create perfect js.

  13. SamGoody says:

    Go Moo Go! Thanks for the great work. Mootools just keeps on rocking!

  14. cainrus says:

    Maybe you, guys, can tell us how can we help build mootools together. Create some contests or something.