mootools / mootools-core Goto Github PK

See subject. I tried the demo here:

http://jsfiddle.net/Fauzu/

See

This is a style/deprecation of language fix.

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.

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

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

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

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);

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

yup

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;
    }
  }

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

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/

See fiddle:

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

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

Thanks!

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.

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;
},

http://jsfiddle.net/MVWb2/

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

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

'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

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.

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

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

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

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));
        };
    });
}
})();

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.

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...

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.fade does not appear to set visibility to none after the affect.

This causes some issues for us.

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

move me to 2000.

Thanks.

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;
  }
};

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

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?

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?

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

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

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...)?

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.

DOMReady should be 100% standalone like Slick.js

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".

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

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();

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);

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

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 {
    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/

Sometimes stripTags mixes some tags, for example and

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

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

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.

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"]).

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)

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'