mootools / mootools-core

MooTools Core Repository

MooTools Core

---

This repository is for MooTools developers; not users. All users should download MooTools from MooTools.net

---

Contribute

You are welcome to contribute to MooTools! What we ask of you:

a. To report a bug:

1. Create a jsFiddle with the minimal amount of code to reproduce the bug.
2. Create a GitHub Issue, and link to the jsFiddle.

b. To fix a bug:

1. Clone the repo.
2. Add a spec.
3. Fix the bug.
4. Build and run the specs.
5. Push to your GitHub fork.
6. Create Pull Request, and send Pull Request.

Do try to contribute! This is a community project.

Building & Testing

Current build process uses Grunt, Grunt MooTools Packager plugin, and Karma related repos.

By default, the build process runs the tests (specs) relevant to the build. To build without testing see the packager build targets.

Building MooTools With Compatibility

This means 1.5.1 that is compatible with: 1.4.6, 1.3.x, 1.2.x, and so on.

Examples

grunt compat             # or
grunt packager:compat    # to only build the source

Building MooTools Without Compatibility

This means 1.5.1 without deprecated code in 1.4.6, 1.3.x, 1.2.x, and so on.

'Proceed at your own risk'
See the changelog or the blog related to each version for migrating your code.

Examples

grunt nocompat           # or
grunt packager:nocompat  # to only build the source

Advanced Building and Testing

See the Gruntfile and MooTools packager for further options.

Examples

# with compat
grunt compat --file=Function    # builds with only Core/Function and dependencies, then tests against specs in Specs/Core/Function
grunt compat --module=Class     # tests against all specs in the Specs/Class *folder* (use --file to limit the build)

# without compat
grunt nocompat --file=Function  # builds with only Core/Function and dependencies, then tests against specs in Specs/Core/Function
grunt nocompat --module=Class   # tests against all specs in the Specs/Class *folder* (use --file to limit the build)

Removing Other Packager Blocks

You'll need to add a specific task to the Gruntfile. See packager's documentation for more examples.

Testing locally

I you want to test your local repo you need just some small steps. Follow these in order:

$ git clone https://github.com/mootools/mootools-core  # clone the MooTools repo
$ cd mootools-core                                     # get into the directory
$ npm install                                          # install de testing tools
$ `npm bin`/grunt test                                 # run the specs!

To test a build in a local browser, you can run the :dev target of that build to start a test server at http://localhost:9876/ and point your browser to it. When you're done testing, pressing Ctrl+c in the window running the grunt process should stop the server.

Example:

$ `npm bin`/grunt compat:dev

If the log is too long, or if you want to store it in a file you can do:

$ grunt > logs.txt   # This will create a new file called logs.txt in the local directory

Testing on Travis & Sauce Labs

Every new Build and Pull Request is now tested on Travis and Sauce Labs. You can also open your own free account on Travis and Sauce Labs to test new code ideas there.

Travis testing uses PhantomJS which is a headless browser. When connected to Sauce Labs then it is possible to choose any number of different Browsers and Platforms. You will need in this case to change the login key so it will match your account.

To add new Browsers in Sauce Labs testing you can make changes to Grunt/options/browsers.json:

• add a new browser to the custom launchers already in the Gruntfile.

   ...
   chrome: {
   	base: 'SauceLabs',
   	platform: 'Linux',
   	browserName: 'chrome',
   },
   ...
  

• add the chosen browser, with the correct builds to .travis.yml:

   env:
   	matrix:
   		- BUILD='compat'     BROWSER='chrome'
  

Browsers, Platforms, and More

This test suite is ready for Travis & SauceLabs. You can also run locally.

Support:

• IE
• Edge
• Firefox
• Safari
• Chrome
• Opera
• PhantomJS (headless browser)

More Information

See the MooTools Wiki for more information

mootools-core's Issues

docs/core/Native/Function wrong link

'MDC Function' links to http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Function
but should point to the new location:
https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Objects/Function
and other links must be fixed, like one in docs/core/Native/Array

1.4 .get("text") breaks in Chrome when el has text-transform: uppercase

2 cases:

markup:
<div class="tag">public</div>
div.tag { text-transform: uppercase; }

calls:
el.get("text") returns public in 1.3.2 and prior and PUBLIC in 1.4.0

http://jsfiddle.net/uwdh7/8/ - works ok in mootools 1.3.2, as expected .get("text") returns public
http://jsfiddle.net/uwdh7/7/ - in 1.4.0, tag.get("text") returns PUBLIC instead, is this getter now running different code?

on the face of it, it is the same... https://github.com/mootools/mootools-core/blob/master/Source/Element/Element.js#L507-510 - is Slick as getter now overriding?

Tested on Chromium 13 and Chrome 14

tokenValue cannot be customized

I wanted to use tokenValue != id .. but it wasnt' working as expected from the code

Array.from Incompatibility with Internet Explorer 8

Using Internet Explorer 8.0.7600.16385 on Windows 7 64-bit.

Not sure if it's relevant, but the page includes both jquery1.6 and mootools 1.3.
Chrome, Firefox, Internet Explorer 9, Safari (Mac and Windows) all work.
Contact me privately for demo URL.

Object doesn't support this property or method.
Error occurs at:

if (typeof item != 'string' && Type.isEnumerable(item) && typeOf(item) != 'array'){


var arrayFrom = Array.from;
try {
    arrayFrom(document.html.childNodes);
} catch(e){
    Array.from = function(item){
        if (typeof item != 'string' && Type.isEnumerable(item) && typeOf(item) != 'array'){
            var i = item.length, array = new Array(i);
            while (i--) array[i] = item[i];
            return array;
        }
        return arrayFrom(item);
    };
    var prototype = Array.prototype,
        slice = prototype.slice;
    ['pop', 'push', 'reverse', 'shift', 'sort', 'splice', 'unshift', 'concat', 'join', 'slice'].each(function(name){
        var method = prototype[name];
        Array[name] = function(item){
            return method.apply(Array.from(item), slice.call(arguments, 1));
        };
    });
}
})();

typeOf

In the documentation of the mootools core it says the typeOf function should return a boolean when the passed argument is undefined, null or NaN. Only I get a string 'null' in return, is this a bug or should the documentation be changed?

http://mootools.net/docs/core/Core/Core ;
'null' - (boolean) If object is undefined, null, NaN or none of the above.

Cheers, Sven

$$().getFirst()

I think there's something wrong with getFirst(). I have a simple MooTools+Html below

window.addEvent('domready', function(){

$('listItem').setStyle('color', 'red');

$('superList').setStyle('border', '1px solid #000000');

alert($$('.lastItem').getLast().get('text'));

});

But the alert() wouldn't pop up. I changed getFirst() to getLast(), and alert() then popped.

Please look into it. I am using IE.

Request should allow people to retrieve XHR raw string (untouched)

Today, Request cannot be use to load raw string unaltered, as processScript removes <script> (regardless of any option).
I need to be able to load webgl glsl code in a custom file syntax...

Missing "wheel" Property on mousewheel Event

randomDomElement.addEvent('mousewheel',function(e){
    e.stop();
    var wheelValue =  e.wheel;
});

e.wheel is undefined but works fine with Mootools 1.3.2

Mootools Doc says it schould work like that: http://mootools.net/docs/core/Types/DOMEvent

Selector bug?

Look in http://jsfiddle.net/hdJGe/9/

The selectors in the form of "selector[property=value]" don't work if the value are in form of "somechars space somechars" (for example option[value="MY VALUE"]).

should use github issues

yup

String.stripTags mixed some tags

Sometimes stripTags mixes some tags, for example and

The following example shows the problem better:
http://jsfiddle.net/kallelat/Taa67/1/

Happens in MT 1.2+

Adding 'paste' event support

It would be great to add a native 'paste' event, I temporary use the following code as a workaround but maybe there is a better approach.

Object.append(Element.NativeEvents, {
  'paste': 2,
  'input': 2
});

Element.Events.paste = {
  base : (Browser.opera || (Browser.firefox && Browser.version < 2)) ? 'input': 'paste',
  condition: function(e) {
    this.fireEvent('paste', e, 1);
    return false;
  }
};

Elements.sort broken in IE6(+?)

http://jsfiddle.net/MVWb2/

Class.Implements creates an instance

Hi,

I'm trying to move from MooTools 1.2 to 1.3 but a weird "bug" appeared.

The problem seems to be using Class.Implements as it creates an instance for every "implemented" class.

In the example below, I have the class C implementing both A and B. In MooTools 1.2.5 the following example
didn't cause any problems, but in 1.3 it creates an instance of both A and B, which of course triggers alert functions.

A simplified example: http://jsfiddle.net/kallelat/cV8sM/1/

I might be wrong and this might even be a feature now. I can solve the problem by using C.implement(A); C.implement(B);
However my codebase is rather huge, so I would not like to do that and besides the code is easier to read if I use Implements: [...]

Is this a bug or a feature? Any comments on this one?

DOMReady has too many dependencies

DOMReady should be 100% standalone like Slick.js

Erroneous symbols and broken code generated by Core Builder

It is as the title says: Erroneous symbols and broken code generated by Core Builder (09/11/2011 @ 7:43 EST)

The issue can be more accurately described with images:

So I load the MooTools-1.4.0 version with NO COMPATIBILITY (named "pat" because I didn't feel like changing the xHTML) and UNCOMPRESSED straight from the Core Builder, unmolested, into my webpage. This is what I am greeted with:

Upon further inspection, it is revealed unto me that... there's a random symbol over there. Okay...

Let's just move that whole line...

Saved changes, about to refresh page...

IT WORKS!

---

Now I download what I'm REALLY after: the MooTools-1.4.0 version WITH COMPATIBILITY (accurately named "pat") and UNCOMPRESSED straight from the website so that I may play around with APE without screwing up its dirty 1.2 version of Moo:

Hello again error. I already know how to fix you:

After fixing it, something HORRIBLE happens when the boxed code (on the right) is called (you can see it easier if you zoom in):

What the eff...

Let's see what it expects versus what it's receiving...

I see...

Since I am in desperate need of getting-on-with-my-life, I applied a horribleuglybadstupidunoptimizedhackish line of code in an attempt to remedy the situation....

And as you can see from the window on the left, everything is working as expected now (again, zoom in to see that there are, in fact, no errors). Yay me.

---

The real question is: what's going on with the core builder... and with the 1.4 compatibility (with 1.2)?
Do note that this same exact code (the script itself) works perfectly fine with 1.3 in compat mode.

Super Duper

There is an issue with MooTools: It's too super-duper. Please, make it crappier, as it's blowing my mind.

An idea to improve String.substitute

Hi,

I wrote my thoughts in a blog that I'm starting, I have few ideas that I want to share with the community and I would like to start to writing about it. Could you please read it and see if this is acceptable to be in Mootools next release?

http://allochi.wordpress.com/2011/08/18/mootools-string-substitution-something-to-thank-mootools-for/

The reason I would like to have this in Mootools is to suggest more stuff that using this function :D

Empty element-properties differs in browsers

An element created with the property like this:
{ property: '' }
will have different results in, for example, Firefox vs Chrome.

In Chrome it is:
<element property />
And in Firefox it is:
<element property="" />

http://jsfiddle.net/ubLw5/

Object.keys (or any other Object methods) doesn't works on Class objects?

I'm trying to understand why I can't get Object.keys() works with object inside a Class object. Let the code speak:

var MyClass = new Class({

    Implements: [Options],

    options: {
        first: 'one',
        second: 'two'
    },

    customData: {
        name: 'string',
        key: 'value'
    },

    initialize: function(options) {

        this.setOptions(options);

        console.log(this.options); // Ok, it works
        console.log(this.customData); // Ok, it works

        console.log(Object.keys(this.options)); // Ok, it works
        console.log(Object.keys(this.customData)); // Empty array... ?!?!

    }

});

new MyClass();

Mootools 1.4, Event 'mousewheel' and Firefox 6.0.2 on Mac OS Lion doesn´t work

See subject. I tried the demo here:

http://jsfiddle.net/Fauzu/

Event "onreadystatechange" does not fire for synchronous ajax requests in Mozilla

I added a simple fix for this issue to MooTools v.1.11. The same could be applied to version 1.2.4. In the XHR.send() function I added the code in bold:

send: function(url, data){
if (this.options.autoCancel) this.cancel();
else if (this.running) return this;
this.running = true;
if (data && this.options.method == 'get'){
url = url + (url.contains('?') ? '&' : '?') + data;
data = null;
}
this.transport.open(this.options.method.toUpperCase(), url, this.options.async);
if(this.options.async)
this.transport.onreadystatechange = this.onStateChange.bind(this);
if ((this.options.method == 'post') && this.transport.overrideMimeType) this.setHeader('Connection', 'close');
$extend(this.headers, this.options.headers);
for (var type in this.headers) try {this.transport.setRequestHeader(type, this.headers[type]);} catch(e){};
this.fireEvent('onRequest');
this.transport.send($pick(data, null));
if(!this.options.async)
this.onStateChange.bind(this).call();
return this;
},

Chrome using innerText not textContent

With the latest version 1.4 Chrome is now using innerText instead of textContent. This was not happening in version 1.3. This causes problems due to a chrome bug that is illustrated here.

http://jsfiddle.net/XBdQq/

Why did this change from
return (temp.textContent == null) ? 'innerText' : 'textContent';
to
return (temp.innerText == null) ? 'textContent' : 'innerText';

The first did not cause us problems where the second did. (line 3126)
http://code.google.com/p/chromium/issues/detail?id=96839

Have Element Create a whole element tree from css selector.

Very nice feature.
I tried to implement it but sometimes it doesn't work.

function createElemFromSelector(expr) {
    var i = 0, elem, name, val;
    if(expr.tag == "*") expr.tag = 'div';
    elem = document.createElement(expr.tag);
    if($.isDefined(expr.attributes)) for(; i < expr.attributes.length; i++) {
      name = expr.attributes[i].key;
      val = expr.attributes[i].value;
      if(name == "text") $(elem).text(val)
      else if(name == "html") elem.innerHTML = val;
      else elem.setAttribute(expr.attributes[i].key, expr.attributes[i].value);
    }
    if(expr.classes) elem.className = expr.classes.join(' ');
    if(expr.id) elem.id = expr.id;

    return elem;
  }
  function makeElemFromCss(elExpr) {
    var elem, levelEl, i = 0, nextAdd, expr, els = new Array(), rtnEls = new Array(), addEls = new Array(), nextPre, preEls = new Array(), j;
    for(; i < elExpr.length; i++) {
      expr = elExpr[i];

      elem = createElemFromSelector(expr);

      els.push(elem);

      function ProcessPre() {
        if(levelEl) {
          for(j = 0; j < preEls.length; j++) {
            if($.isElement(levelEl.firstChild)) levelEl.insertBefore(preEls[j], levelEl.firstChild);
            else levelEl.appendChild(preEls[j]);
          }
        } else {
          rtnEls = preEls;
        }
        levelEl = preEls[0];
        preEls = new Array();
        nextPre = false;
      }

      function ProcessAdd() {
        if(levelEl) {
          for(j = 0; j < addEls.length; j++) {
            levelEl.appendChild(addEls[j]);
          }
        } else {
          rtnEls = addEls;
        }
        levelEl = addEls[0];
        addEls = new Array();
        nextAdd = false;
      }

      switch(expr.combinator) {
        case "~":
        case "+":
          if(nextPre) ProcessPre();
          addEls.push(elem);
          nextAdd = true;
          if(elExpr.length == i + 1) ProcessAdd();
          break;
        case "!~":
        case "!+":
          if(nextAdd) ProcessAdd();
          preEls.push(elem);
          nextPre = true;
          if(elExpr.length == i + 1) ProcessPre();
          break;
        case ">":
        case " ":
        default:
          if(elExpr[i+1] && (elExpr[i+1].combinator == "+" || elExpr[i+1].combinator == "~")) {
            addEls.push(elem);
          } else if(elExpr[i+1] && (elExpr[i+1].combinator == "!+" || elExpr[i+1].combinator == "!~")) {
            preEls.push(elem);
          } else {
            if(nextAdd) ProcessAdd();
            else if(nextPre) ProcessPre();

            if(levelEl) {
              levelEl.appendChild(elem);
            } else {
              rtnEls = [elem];
            }
            levelEl = elem;
          }
          break;
      }
    }

    return rtnEls;
  }
  function createFromCss(selector) {
      var elems = new Array(), parsed = Slick.parse(selector), i = 0, j = 0, elemExpr;
      for(; i < parsed.expressions.length; i++) { // loop through all the expressions
        elemExpr = parsed.expressions[i];

        elems = elems.concat(makeElemFromCss(elemExpr));
      }
      return elems;
    }
  }

DOMMouseScroll problem in mootool 1.4 Core

Hello,

In the last mootool 1.4 core, there is a little bug on line 1460.
The "DOMMouseScroll" event is mission in the condition so the this.wheel can't be used.

In place of:
else if (type == 'click' || type == 'dblclick' || type == 'contextmenu' || type.indexOf('mouse') == 0){

the should be:
else if (type == 'click' || type == 'dblclick' || type == 'contextmenu' || type == 'DOMMouseScroll' || type.indexOf('mouse') == 0){

and everything work fine after this modification.

Thank you for this wonderfall framework

Bobjpg

Fix Slick menu in docs

See Slick in the menu at http://mootools.net/docs/core

Remove use of `argument.callee` in Element.Delegation.js

See

This is a style/deprecation of language fix.

event.wheel missing in Firefox in mt 1.4

If you add a mousewheel event to an element, then the resulting event instance is missing the wheel property in Firefox (testing in v 6.02). Event ok in chrome. Event.wheel present in 1.3.

JSON module should add stringify and parse methods

The JSON module should add the stringify and parse methods to the JSON object, if they are not present.

This will make Mootools compatible with JSON dependent scripts out of the box, cross-browser.

Bound functions as constructors

According to: https://gist.github.com/1120592

Function.bind should return a bound function that should work as a constructor.

Animation slowdowns in Chrome 13

I've started noticing a decrease in animation smoothness, at first I thought it was because of some extra rendering I was doing on a new project of mine (moo1.3), but today I updated some assets on my folio site (moo1.2), and noticed that a side-scroller I have, got in fact pretty choppy.

Now that I think about it the choppiness started right after updating to Chrome 13.

I've posted my thought about this on twitter, and it seems I'm not the only one who noticed this, ie. https://twitter.com/fuzzyspo0n/status/99766790464348160

I can't provide a real test-case for this. But as I see it, in version 12, the animation was smooth from 0% to 100%, but in version 13, the animation is smooth from 0% to, say, 70%, slows down a bit, and continues to 100% - it simply has these random slowdowns.

.toggleClass('class', force) exists, but .toggle(force) doesn't exist

.toggle(force) should exist! And maybe it will soon!

Creating a "this.Document" variable interferes with some versions of Java

Creating a "this.Document" variable interferes with some versions of Java. So far it breaks on the following versions, using IE7 on Windows XP:

• JRE 6.0 Update 7
• JRE 6.0 Update 6
• JRE 6.0 Update 5
• JRE 6.0 Update 4
  [Due to time constraints JRE 6.0 to JRE 6.0 Update 3 were not tested]
• JRE 5.0 Update 22
  [Due to time constraints JRE 5.0 Update 16 to JRE 5.0 Update 21 were not tested]
• JRE 5.0 Update 15
  [Due to time constraints JRE 5.0 Update 1 to JRE 5.0 Update 14 were not tested]
• JRE 5.0

Simply removing line 153 from Browser.js :
this.Document = document.$constructor = new Type('Document', function(){});

Or changing the variable name to something other than "Document" e.g. "Document2" fixes the problem. However this would require further modifications throughout the code to reflect this change.

An example of this can be demonstrated on jsFiddle where the "Result" window only shows a white box when one of the versions of Java above is installed:
http://jsfiddle.net/ZeZvp/1/

Changing to Mootools 1.2.5 fixes the problem as the variable does not exist in that code base, allowing the applet to load.

Does anyone know whether this can be fixed within JavaScript or is this a problem with Java? The quick fix at the moment would be to ask people to update their version of Java. However I am worried about the people who dont have the rights, know how or time to do so.

Thanks

getCoordinates failure

element {
    left: 50%;
    margin-left: -10px;
}

element.getCoordinates(element.getOffsetParent());

fails, if "element" has a percentage as "left" value and a negative margin-left.
The calculated "left" value in pixel ignores the margin.

EDIT:

Demonstration using Drag from MooTools More:
http://jsfiddle.net/dHCXb/

Doc bug report

In the Element doc, for eliminate description, the syntax is wrong, current is:

Syntax:
myElement.retrieve(key);

I think it should be:

myElement.eliminate(key);

Element.fade no longer set visibility: none

Element.fade does not appear to set visibility to none after the affect.

This causes some issues for us.

Placeholder issue

move me to 2000.

Thanks.

Bug in IE with HTML5 elements

Hello

I've been struggling with a bug since Mootools 1.3 (which isn't there in 1.2) with regards to HTML5 elements. I've checked it in 1.4 and it is still there. I posted a bug in lighthouse about it months ago: https://mootools.lighthouseapp.com/projects/2706/tickets/1218-bug-in-ie-with-html5-elements

This only seems to occur on IE8, and is preventing us from using anything apart from 1.2.6 on real world sites!

When I use a function like getElement, or getElements, on an element that contains HTML5 elements I get the following errors:

Invalid procedure call or argument - line 2417, character 47
Object doesn't support this property or method - line 5327, character 2

I tracked it down to this code:

if (this.starSelectsClosedQSA) for (i = 0; node = nodes[i++];){
    if (node.nodeName > '@' && !(hasOthers && uniques[this.getUID(node)])) found.push(node);
} else for (i = 0; node = nodes[i++];){
    if (!(hasOthers && uniques[this.getUID(node)])) found.push(node);
}

It seems to be the nodes[i++] thats causing the problem.

Changing the code to the following seems to fix the problem.

if (this.starSelectsClosedQSA){
    for (i = 0; i<nodes.length;i++){
        node = nodes[i];
        if (node.nodeName > '@' && !(hasOthers && uniques[this.getUID(node)])) found.push(node);
    }
} else {
    for (i = 0; i<nodes.length;i++){
        node = nodes[i];
        if (!(hasOthers && uniques[this.getUID(node)])) found.push(node);
    }
}

Can you PLEASE pull this change in. Its a really frustrating issue.

Thanks,
Ryan

request.JSON docs

The docs at http://mootools.net/docs/core/Request/Request.JSON say

Wrapped Request with automated sending and receiving of JavaScript Objects in JSON Format.

But actually there is no automation for sending data in JSON form. It only decodes the response but does not encode the sending.

I would also propose that it should add correct headers as Content-Type for JSON request should be "application/json".

MooTools Selector documentation

There used to be a page in MooTools 1.2 under Utilities which thoroughly went through selectors like starts-with (^=), ends-with ($=) but somehow during the reshuffle of 1.3 documents this information is NOT in the MooTools documentation, and the only place to review it other than the source code is in the MooTorial. Is someone working on a rewrite of the Selector page? Is that why this valuable information has disappeared?

Description of Browser.Plugins.Flash simply isn't true

In the docs, it states "Browser.Plugins.Flash - (boolean) - True if Flash is present.", which simply isn't true, as seen on this jsfiddle

So either, we need to change the documentation to say that Browser.Plugins.Flash is an object with some properties that you can use to test if flash is installed (currently, doing something like Browser.Plugins.Flash.version !== 0 works), or we need to fix the functionality, or we need to do both, and add something like Browser.Plugins.Flash.available (=== true or === false)

Element.implement failed if a dom node already dollared in ie6,7

For those browsers who doesn't have native Element prototype, such as ie6-7, if a dom node has already been document.id'd, the newly implemented methods in Element will be no more applied to the element. So, you can't dynamically and asynchronously attach Element.dimension module into the page but have to load everything together with the core of mootools simultaneously.

in these browsers, when we fetch a element with document.id, mootools will detect the property and flag of the element, named $family. if undefined (despite of nocash), the implemented methods will be mixed into the element as static ones, which i thought, is the main cause of this problem and the mechanical drawback of mootools.

So, why didn't mootools solve this as the jQuery way, or let document.id return a mootools-specified object ?
May i have your premier design ideas about this ？

Element.Properties:html doesn't accept multiple arguments, as documented

element.set( "html", ... ) with multiple arguments does not work as documented: http://mootools.net/docs/core/Element/Element#Element-Properties:html

See: http://jsfiddle.net/6vrBU/

It works correctly (as documented) in 1.2.

Add Element.Properties.value.set

See this jsfiddle in old IE: http://jsfiddle.net/JemX8/2/

we fixed Element.Properties.value.get already: dcc2dcafd

disable Request onTimeout with async = false

Timeout handling does not work with "async: false".
onTimeout is triggered always after xhr.send() returns.

Here is a testcase:
http://jsfiddle.net/kguelzau/thxA4/

Should be

if (!this.options.async) this.onStateChange();
**else** if (this.options.timeout) this.timer = this.timeout.delay(this.options.timeout, this);

insertAdjacentHTML

I saw it here:

http://hacks.mozilla.org/2011/08/aurora8/

They've put a benchmark here:

http://jsperf.com/insertadjacenthtml

Looks interesting for 2.0 or maybe a 1.5.

Looks like it's widely supported (look at jsperf's table).

Element.getParent() with multiple selectors

See fiddle:

http://jsfiddle.net/LwPRF/2/

div.page should be returned, instead div.window is.

Thanks!

Passing in an undefined variable to Element results in value being the string 'undefined'

If you create a new input and pass in an undefined variable then the value of that input is now set to the string 'undefined'. In mt1.3 it correctly results in an empty string.

var value;
var input = new Element('input', {'value': value})
var inputValue = input.get('value');
console.log(inputValue); // returns the string 'undefined'

Element.getComputedSize not working with IE and relative dimensions.

this was lighthouse ticket 537

The problem:
the function Element.getComputedSize doesn't return correct values of width and totalWidth.

Browsers affected:
Internet Explorer 7/8.

When this bug happen:
when the element has a relative width (ex. % or em).

Example:
http://jsfiddle.net/NKjoep/VvrAs/

Here also a JSSpec example:
http://dl.dropbox.com/u/1840263/getComputedSize/test1.html

So in these example, the Element.getSize is working well.
Why not to rely on it? Element.getComputedSize shouldnt get the actual real size
and then add the optional parameters (such as padding, borders...)?

'readonly' atribute can not be set

This:
el.setAttribute('readonly', 'readonly');

does not work. Neither does this:
el.set('readonly', 'readonly');