Opera has conceived a silly tactic planned for Opera 10 user-agent string.

The problem is that there are scripts that expect the browser major version to single-digit and will fail if it is not.

Since "10" not a single digit, these scripts fail.

Opera has mitigated that problem by changing the user-agent to 9.80 and publishing the following warning:

Browser sniffing ? unless you?re writing a web stats application ? is always a bad idea. It?s a misguided attempt to send different content to different user agents. This is never scalable ? you can?t change every website you?ve ever made every time a new browser version comes out. It is also not future-proof, as highlighted by this article.

Ineffectual and meaningless little blurb there. Those badly written sites that used (poor) browser detection will not break from Opera. Opera spoofing their own user-agent string helps reaffirm the misconception that the authors' browser detection worked. Posting up a little warning that not everyone will read does not make an example.

The blurb states that Browser detection is used "to send different content to different user agents". Not always true. In fact, browser detection is more often used on the client to work around an perceived incompatibility. Since Opera is wrong on that count, it makes the blurb seem even less relevant, as an author who read it might still try to justify or rationalize his approach by saying "but that's not why I used browser detection."

Browser detection scripts cause forwards-compatibility and maintenance problems. However, to not be able to parse out a number is not only not smart, it shows very poor coding skill.

Opera states that version 11 will have "11" in the user-agent string.

My opinion is somewhat in line with Doug's on this one (that Yahoo 360 URL is an awful URL).

If you are a developer, check your code. It really isn't hard to do this stuff correctly. It really isn't.

Where I disagree with Doug is "Opera has been forced to lie."

Opera developers made a decision to lie, as explained by Opera. They were not forced.

An alternative to that choice is for Opera to not cater to badly authored pages and simply let them break.

Breaking sites is bad in the short term because it renders pages unusable. However, it is good in the larger scheme of the web in the long run. By driving home a hard lesson, Opera could teach developers to not use browser detection by providing an historical lesson.

The first sensible opinion on the matter was Hallvord's post from December, 2008., where he pointed out that Bank of America and Live.com failed in Opera 10. The entry describes the reason: Faulty parsing of the User-Agent string, and redirecting to the "not supported page".

You'd think that with the intense development Microsoft has been lavishing on live.com they would have found somebody capable of writing a usable browser sniffer (or ideally a person clever enough to say "wait, we don't really need one - what if we just use feature detection instead?"). Think again..

Of course, Microsoft has been advocating detection "best practices" for years, despite well reasoned arguments to stop doing that (G. Talbot, T. Zijdel).

Opera should be less myopic and stop worrying about breaking badly authored sites. Web developers should be less myopic, and build maintainable, forwards-compatible solutions.

Function Binding

A bind function wraps a function in a closure, storing a reference to the context argument in the containing scope.

This allows the bound function to run with a predetermined context.

Variable this

When a function is passed as a reference, it loses its base object. When the unbound function is called, the this value is the global object.

How Binding Works

By storing a reference to the desired object in a closure, this argument can be bound.

In it's simplest form, bind looks like:-

Function.prototype.bind = function(context) {
  var fun = this;
  return function(){
    return fun.apply(context, arguments);
  };
};

Why Binding is Useful

Binding is often necessary when passing function references. For example:-

var updater = {
  fetch : function() {
    alert(this.time++);
  },
  time : 0
};
// setTimeout(updater.fetch, 500);
setTimeout(updater.fetch.bind(updater), 500);

The commented-out call to setTimeout would result in a call to updater.fetch with the global object for the this argument. this.time would be undefined, and this.time++ would result in NaN.

A bind function that does only binding accomplishes a trivial task. In most cases, a closure can just be used where binding is needed.

Binding in the Wild

Most JavaScript libraries handle binding internally. These libraries also include a partial apply for their bind function.

Partial Apply

Partial application is setting parameter values of a function call before it is called. A partial apply function usually looks like:-

/** 
 * Return a function that prepends the 
 * arguments to partial to this call and 
 * appends any additional arguments.
 */
Function.prototype.partial = function() {
  var fun = this,
      preArgs = Array.prototype.slice.call(arguments);
  return function() {
    fun.apply(null, preArgs.concat.apply(preArgs, arguments));
  };
};

This allows us to program in a dynamic, functional, less OO way. For example:

function setStyle(style, prop, value) {
  return style[prop] = value;
}

// Create a setBgColor function from 
// partial application of setStyle.
var setBgColor = setStyle.partial(document.body.style, "background");

// Change the body's background color.
setBgColor("red");
setBgColor("#0f0");

Disadvantage

Partial application requires an extra function call, plus a call to concat for the extra arguments.

Partial application can make debugging trickier, since there is an extra layer of indirection to the real method.

Bind + partial apply can be used to force the this argument of a prototype method to always be the of the instance. This is inefficient and often leads to messy, tangled function decomposition. Libraries that bind every method do so out of ignorance of the language, and are best avoided.

EcmaScript New Language Feature

The forthcoming version of EcmaScript (now called EcmaScript Harmony) will include Function.prototype.bind(context). A native bind should outperform any other bind function.

This was something Peter brought up for EcmaScript 4, but appears to be making way into the revised EcmaScript Harmony.

Mark Miller wrote out a "self-hosted" version of EcmaScript's proposed Function.prototype.bind. It is:-

Function.prototype.bind = function(self, var_args) {
   var thisFunc = this;
   var leftArgs = Array.slice(arguments, 1);
  return function(var_args) {
    var args = leftArgs.concat(Array.slice(arguments, 0));
    return thisFunc.apply(self, args);
  };
};  

After looking at the ES Harmony proposal, and looking at a few versions of bind functions, I decided to write a better one that does exactly what the ES Harmony's bind does, but with greater efficiency than the current libraries offer, and whose, length property was 1.

Although unnecessary, this is a welcome addition to the language. A native bind will outperform any user-defined bind function and will result in fewer closures.

The Rundown

Before I give a critique and rundown, I have a test.

Library Comparison Test

1. Garrett's Bind

   This bind was, by far, the most efficient in tests #1, and #4, and nearly ties Base 2 in test #2 (Base 2 was about .5 ms faster) . This function requires no additional code or functions.

2. Base2 bind

   Second performance-wise.

   Requires only a top level _slice function (trivial), and performs a strategy for extra arguments.

3. Dojo's hitch

   Dojo was fast with pure bind, but slower with partial apply.

   This function requires many other functions and has an additional complication of accepting strings and arguments of different order.

4. Ext-js Function.prototype.createDelegate

   Performance was slow. This function requires no importing of external functions.

5. Mark Miller's bind

   Requires no external dependencies. While it gets a 10 for simplicity and aesthetics, this function was not as fast, and for pure bind (no partial apply) was not nearly as fast as it should be.

6. Prototype's Function.prototype.bind

   Performance was fair. Requires several extra functions + browser detection. The function is used very heavily internally.

7. Mootools Function.prototype.bind

   Performance times were poor and the results for two tests were wrong. were wrong.

   The entire mootools.js is required for the bind function. The library adds a $family property, and makes other changes to Array.prototype.

8. YUI 3 bind

   Performance time was fair. The results for test#2 are wrong because the call's arguments are prepended, not appended. This is by design.

   Having the call's arguments prepended is an unusual design decision. It might seem unintuitive, and confuse developers who are used to the more common version, as seen in Prototype, Base2, and the official EcmaScript proposal.

   The amount of code YUI's bind depends on is staggering.

Pass the Parmeźan

Many of the libraries have long chains of function calls. A bind function does not need and should not require the inclusion of several other functions.

Prototype JS requires the $A function, which requires Prototype.Browser to determine which $A function. Browser detection has absolutely no place in Function binding. ($A also calls toArray conditionally, but that will not happen in this case.)

Dojo is almost as bad. Dojo's hitch function has the arguments in reverse order and requires dojo.global, dojo._hitchArgs, dojo._toArray, and dojo.isString.

Mootools has very strewn code. The broken bind function required an additional 108 lines of Mootools.

YUI is the most grandiose. Function YUI.bind(f, o) is found in "oop.js". File oop.js requires over 120k of "prerequisite" files in yui.js and yui-base.js, coming to a total of over 160k. Just for bind. YUI 3 seems to suffer from over-engineering and BUFD, which is typical in waterfall shops.

YUI's 'array' module did not seem to load or evaluate properly, so code from the yui-base file was copy-pasted.

Worth Using?

The best bind functions are fast, do not require other library functions, and are fairly simple.

But is a Bind Function Necessary?

No. Binding can be achieved with an inline closure where it is needed and partial application is not necessary.

Here is example 1, without using bind.

var updater = {
  fetch : function() {
    alert(this.time++);
  },
  time : 0
};
setTimeout(function() { updater.fetch(); }, 500);

A native Function.prototype.bind will allow for cleaner binding, without the need for creating a closure. As native code, it will be faster and more reliable. Function.prototype.bind is not necessary, but is a welcome addition to the language.

Why All the Fuss?

Being aware of what libraries do and identifying and learning from the mistakes of libraries helps developers avoid such mistakes by learning what the library does. Developers do not need the burden of large, tangled, and often buggy library dependencies.

Look at The Code

What the library's bind function does and how the library uses that function internally is a step to take in assessing the library's quality.

A developer can make a more responsible and professional choice by avoiding a library that makes heavy use of a slow-spaghetti bind function.

My Version

The following function is the fastest bind function for pure bind (no partial apply). It is more than three times as fast as Base2, the second fastest bind function tested here.

Here is my version of the bind function.

/**
 * @param {Object} context the 'this' value to be used.
 * @param {arguments} [1..n] optional arguments that are
 * prepended to returned function's call.
 * @return {Function} a function that applies the original
 * function with 'context' as the thisArg.
 */
Function.prototype.bind = function(context){
  var fn = this, 
      ap, concat, args,
      isPartial = arguments.length > 1;
  // Strategy 1: just bind, not a partialApply
  if(!isPartial) {
    return function() {
        if(arguments.length !== 0) {
          return fn.apply(context, arguments);
        } else {
          return fn.call(context); // faster in Firefox.
        }
      };
    } else {
    // Strategy 2: partialApply
    ap = Array.prototype,
    args = ap.slice.call(arguments, 1);
    concat = ap.concat;
    return function() {
      return fn.apply(context, 
        arguments.length === 0 ? args : 
        concat.apply(args, arguments));
    };
  }
};

This function was not included in APE because it was not needed. This function may be used by libraries who wish to continue using a bind function with the benefit of faster performance.

Technorati Tags: JavaScript

Most libraries try provide some functionality for finding an element's position, but fail in all but the simplest cases.

I created a test page to demonstrate the libraries' results of finding an element's position and the time it takes for them to succeed or fail.

Test Page

Compare JavaScript Libraries

Demos are Not Unit Tests

These two demos don't cover all of the complexities in finding an element's position. I didn't even touch tables. There are also complications with padding and border on HTML root element. Unfortunately, IE8b1 doesn't support CSS on the HTML root element (connect id 354453), so it can't be tested.

APE guards against all of the other problems by having a test suite that tests this function with combinations of these cases.

Technorati Tags: APE JavaScript

I was prompted to do a code review on PrototypeJS. Here is a partial review.

Ten Issues

• Modification of Host Object - Non standard, doesn't work the same in all browsers. Don't do it!
• Class.Methods.addMethods -
  • Don't rely on a Function's toString!
  • Don't introduce special behavior based on function Decompilation!
  • The mimicing of class based inheritance through closures to get $super to work requires a significantly augmented scope chain.
• The Dollar Function - Meaningless and extremely inefficient
• Element.Methods.visible - misnamed, non-reflective, and buggy/unreliable!
• More Modifications to Host objects
• Object.extend - Don't forget the JScript DontEnum bug!
• $A - Relying on object's toString -
• readAttribute - Don't rely on Function Decompilation
• Ajax.Request - Add an Underscore?
• Broken unescaping of HTML Strings
• Unnecessary use of with statement
• Enumerable.include - Strict Equality or 2n with Loose Equality
• getDimensions - Don't Expect clientWidth to be non-zero in IE
• cumulativeOffset - doesn't account for borders, scroll offsets, or magic BODY.

Okay, so it's more than 10, and could be even more, but I have to stop somewhere!

Modification of Host Object

A Host object is an object provided by the Host environment, e.g. document, event, an element.

PrototypeJS relies on modifying Host objects as a part of its core approach. There are several problems with this approach.

• There is no requirement in the EcmaScript specification that requires Host objects to be modifiable (although they usually are).
• There is no requirement in the EcmaScript specification that the Host environment expose for its Host objects a constructor with an associated prototype.
• There is no requirement in the EcmaScript specification that objects expose a __proto__ property.
• There is no guarantee by any standard that there will be a __proto__ property present for an Element or what value, if any, it will hold.

The fact that Mozilla exposes the prototypes of Element, et c is useful in that it allows developers to provide quick patches for new or broken features that lack proper support. However, this feature can't be reliably used for websites that are expected to run in multiple browsers.

Class.Methods.addMethods

Class.Methods.addMethods relies on the approach of calling toString on a function, expecting to get back the source code, as it originally appeared.

if(value.argumentNames().first() == "$super")

A few significant problems:

• Function.prototype.toString is not required to return the source code of the function

  Function.prototype.toString is guaranteed only to return an implementation-dependent representation of the function as a FunctionDeclaration [or FunctionExpression] (spec errata, has been fixed). (§15.3.4.2).

  Opera mobile follows the spec but takes the liberty of not returning the source code of the function.

• Even if relying on the name of a function's formal parameter were guaranteed, doing so would make implementation code fragile because it would be impossible for a human (or compressor) to rename it (YUI Compressor bug).

  Object.extend(Function.prototype, {
    argumentNames: function() {
      var names = this.toString().match(/^[\s\(]*function[^(]*\((.*?)\)/)[1].split(",").invoke("strip");
      return names.length == 1 && !names[0] ? [] : names;
    },
  

Providing a toString that returns helpful debugging info for objects is generally good advice.

However, the return value of a function's toString cannot be expected to be anything other than a string value. It should not be relied on. Unfortunately argumentNames will choke on a Function object that has a custom toString. This problem will happen in every browser.

Example: Programmer-defined toString Causes Problem with Object.extend

function WidgetFactory(){}
WidgetFactory.toString = function(){ return"[WidgetFactory constructor]"; };

If argumentNames() is called on WidgetFactory, the first call to match() will return null. Then, when split() is called, a TypeError will be thrown.

It would be less error-prone for PrototypeJS to use:

    var names = Function.prototype.toString.call(someFunction);
    

This avoids the mistake of relying on the function instance's toString, however, the approach still has two significant problems:

1. relies on the source code and named formal parameters of the function on which it is called (problem 1).
2. Function.prototype.toString is still not required to return the source code of the function Function.prototype.toString is guaranteed to return an implementation-dependent representation of the function as a FunctionDeclaration [or FunctionExpression] (spec errata). (§15.3.4.2), and in fact, Opera mobile follows the spec correctly, but takes the liberty of not returning the source code of the function.

Relying on Function Objects' toString

Do Not Rely on Return Values from Function Objects' toString!

In general, toString should not be parsed or relied upon for data formats. toString is useful for debugging. In October 2007, I pointed out how Dojo and jQuery made this mistake. Hallvord has been writing against relying on Function Decompilation for well over a year, as it resulted in problems in PrototypeJS and jQuery running in Opera Mobile.

The Dollar Function

PrototypeJS is built on the approach of modifying Host objects. This is the cornerstone of the library's problems. The library will try to modify the built-in prototype of an XPConnect wrapped prototype if it assumes the browser can do that. Otherwise, it will add properties to the element itself.

The primary accessor to these modified Host objects is through that dollar function.

Law of Demeter

Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. (LoD).

I'll come back to explain how Prototype.js' modifications to Host objects violate LoD, and the problems associated with that.

What Does $ Do?

• $ does not have a clearly defined meaning as to what the function actually does.
• The dollar sign is intended to be reserved for machine-generated code.

PrototypeJS $ function gets an element or array of elements. Calling $ results in a bare minimum of three function calls: $, isString, and Element.extend and a maximum of over 135 function calls.

function $(element) { 
  if (arguments.length > 1) { 
    for (var i = 0, elements = [], length = arguments.length; i < length; i++) 
      elements.push($(arguments[i])); 
    return elements; 
  } 
  if (Object.isString(element)) 
    element = document.getElementById(element); 
  return Element.extend(element); 
} 

Call Stack of $ (best case)

$ -> isString
  -> document.getElementById
  -> Element.extend

Count of Functions from $ (best case)

$................................+1 
 +--isString.....................+1
 +--document.getElementById.....(+1) (when isString(element) is true) 
 +--Element.extend...............+1 
    ~--Prototype.K||(anonymous)...0 (alias, second time, only. Prototype.K only if SpecificElementExtensions)
Sub-total_________________________3 (4 when isString(element) is true).

Calling $(document) then $(document), there will be many function calls the first time, and never any fewer than three calls the second time.

Element.extend = (function() {
  if (Prototype.BrowserFeatures.SpecificElementExtensions)
    return Prototype.K;

  var Methods = { }, ByTag = Element.Methods.ByTag;
  Object.extend(function(element) { 
      if (!element || element._extendedByPrototype || 
          element.nodeType != 1 || element == window) return element; 
      var methods = Object.clone(Methods), 
        tagName = element.tagName, property, value; 
      // extend methods for specific tags 
      if (ByTag[tagName]) Object.extend(methods, ByTag[tagName]); 
      for (property in methods) { 
        value = methods[property]; 
        if (Object.isFunction(value) && !(property in element)) 
          element[property] = value.methodize(); 
      } 
       element._extendedByPrototype = Prototype.emptyFunction; 
      return element; 
  }, {
    refresh: function() {
      // extend methods for all tags (Safari doesn't need this)
      if (!Prototype.BrowserFeatures.ElementExtensions) {
        Object.extend(Methods, Element.Methods);
        Object.extend(Methods, Element.Methods.Simulated);
      }
    }

  extend.refresh();
  return extend;
})();

Element.extend, first call

However, during the first call to $(document), there is a check to Prototype.BrowserFeatures.SpecificElementExtensions. This is done because when SpecificElementExtensions is true, then the Library attempts to add the properties to DOM interface prototypes, e.g. HTMLHeadingElement.prototype. This happens elsewhere in the code, only when a __proto__ property returns a truthy value on created elements. If this feature is supported, the author has makes modifications to the DOM object interfaces, e.g. "HTML" + element.tagName + "Element", et c, but only when the userAgent does not match /Apple.*Mobile.*Safari/. (He makes said modifications elsewhere in the code, Element.addMethods -> findDOMClass).

Element.extend's closure calls Object.extend (needs review) to add the refresh() method to element.extend (rather than perform a simple assignment). The closure then calls extend.refresh() before returning the method extend, which gets assigned to Element.extend.

+ Element.extend's closure -> Object.extend -> extend.refresh -> Object.extend...3
                                      Object.extend...1
subtotal:_____________________________________________9

calls: 5, Depth: 3 These calls are done when the file is loaded. They don't affect performance of $.

After extend has been assigned to Element.extend, it is invoked. Element.extend calls Object.clone, which calls Object.extend, then ByTag, Object.extend, n calls to isFunction, n calls to methodize, where n is the number of properties of methods. The element is then "methodized", which adds Ajax, et c to a FORM element.

$ -> isString..........................................(2)
     document.getElementById...........................(+1) (when isString(element) is true)
     Element.extend ->  Object.clone -> Object.extend..(2)
                        ByTag -> Object.extend.........(2) (depends on tagName).
                        isFunction.....................(n = Size(methods) = 64 + 8)
                        methodize......................(n = Size(methods) = 64 + 8)
Total:_________________________________________________151

Calling $("sp-searchtext") results in 151 function calls the first time it is called. Non-form elements will have 133 calls the first time.

This happens for every object that is got by dollar function for browsers that don't support modifying DOM prototypes.

It considerably more complex and inefficient the first time around, when SpecificElementExtensions is false:

Object.extend(Methods, Element.Methods);
Object.extend(Methods, Element.Methods.Simulated);

Where is $ Used Internally?

All of the Element.methods of PrototypeJS functions (the ones that got "methodized" in dollar, use the dollar function, as well, adding extra overhead of a function call.

This allows each of Element.methods to be used as a static method. This also adds considerable extra cost, though, to each call.

Element.Methods = {
// (GS) visibility is not display!
  visible: function(element) {
// (GS) style properties do not reflect element state.
// The value 'inherit' is not considered.
    return $(element).style.display != 'none';
  },

Element.Methods.visible does not deal with CSS visibility, but instead returns the style.display != 'none'. The display property does not reflect the currentStyle or computed style. Also, the CSS display property can have the value inherit.

Other Element.Methods functions that use the dollar function are more expensive. For example:

// (GS) Avoid this long chains of calls. Hard to debug.
// (GS) calling Element.extend on each element is expensive, 
// up to 1600+ function calls for a FORM with 10 elements in IE.

  descendants: function(element) {
    return $A($(element).getElementsByTagName('*')).each(Element.extend);
  },

...

var Enumerable = {
  each: function(iterator, context) {
    var index = 0;
    iterator = iterator.bind(context);
    try {
      this._each(function(value) {
        iterator(value, index++);
      });
    } catch (e) {
      if (e != $break) throw e;
    }
    return this;
  },

...


Object.extend(Array.prototype, {
  _each: function(iterator) {
    for (var i = 0, length = this.length; i < length; i++)
      iterator(this[i]);
  },

Considering a FORM with 10 input elements and nothing else, there will be:

Element.descendants...................1
    $A-->Array........................2
     +--$.............................151
        +--getElementsByTagName('*')..1
     each.............................1 x 10 (ten INPUT elements)
      +--bind.........................1 x 10 
      +--_each........................151 x 10 (151 methods, ten INPUT elements)
TOTAL.................................1685

One thousand, six hundred, and eighty-five function calls.

The call to isFunction in Element.extend might be something that could be refactored:

value = methods[property];
Object.isFunction(value)

Variable methods is a collection of functions. Calling Object.isFunction(value) should always return true here and this is something that the author can have control over because he owns methods (Law of Demeter).

Always Use Dollar

When using PrototypeJS, it is uncertain what properties will be present on an Element. This is because PrototypeJS may have already modified that element or its associated prototype. This dilemma of ambiguity can be avoided by the PrototypeJS user always using the dollar function and depending on PrototypeJS.

$("adiv").parentNode.show(), will have unexpected results, and will result in error in IE, if the parentNode has not been previously modified via Element.extend()

$($('adiv').parentNode), will result in no less than seven function calls, and that is only after $('adiv') has been called and $($('adiv').parentNode) has been called.

More Modifications to Host Objects

I'm going to back up a little bit and look at details I skipped over, the modification Host objects.

LoD Recap

If the implementation's internal code undergoes change, or if other browsers provide similar properties with slightly different implementation then the code that relies on assumptions of implementation-specific details based on those properties (col.__proto__) will fail. Implementations have been known to change, in this regard (bug 390411)

function findDOMClass(tagName) {
    var klass;
    var trans = {
      "OPTGROUP": "OptGroup", "TEXTAREA": "TextArea", "P": "Paragraph",
// (GS) et c...    
    };

    if (trans[tagName]) klass = 'HTML' + trans[tagName] + 'Element';

// (GS) Does not provide any feature detection about the object.
    if (window[klass]) return window[klass];
    klass = 'HTML' + tagName + 'Element';
    if (window[klass]) return window[klass];
    klass = 'HTML' + tagName.capitalize() + 'Element';
    if (window[klass]) return window[klass];

    window[klass] = { };

// (GS) Does not provide any feature detection about the object.
    window[klass].prototype = document.createElement(tagName).__proto__;
    return window[klass];
  }

  if (F.ElementExtensions) {
    copy(Element.Methods, HTMLElement.prototype);
    copy(Element.Methods.Simulated, HTMLElement.prototype, true);
  }

  if (F.SpecificElementExtensions) {
    for (var tag in Element.Methods.ByTag) {
      var klass = findDOMClass(tag);
      if (Object.isUndefined(klass)) continue;
      copy(T[tag], klass.prototype);
    }
  }

The findDOMClass assumes that the window will have an object based on tagName or that if this is not the case, then the element's __proto__ property will be readable.

There is no guarantee by any standard that there will be a __proto__ property present or what value it will hold, if any.

There is no guarantee by any standard of an HTMLTableRowElement on window, nor any guarantee of what modifying its prototype will have. The library makes broad assumptions and performs no capability tests.

Replace the Host Environment's Element?

Not satisfied by altering over certain Host environments' Element with its own properties, PrototypeJS seeks to create a constructor to replace those environments' Element with its own, copying over all enumerable properties from the Host's Element. In Firefox, this includes all of QueryInterface.

This creates the dilemma of having a debilitated Element. Where previously, in Firefox, Element was native code, and Element.prototype.TEXT_NODE had the value 3, now, Element is a PrototypeJS constructor function and Element.prototype.TEXT_NODE is undefined.

(function() {
  var element = this.Element;
  this.Element = function(tagName, attributes) {
    attributes = attributes || { };
    tagName = tagName.toLowerCase();
    var cache = Element.cache;
    if (Prototype.Browser.IE && attributes.name) {
      tagName = '<' + tagName + ' name="' + attributes.name + '">';
      delete attributes.name;
      return Element.writeAttribute(document.createElement(tagName), attributes);
    }
    if (!cache[tagName]) cache[tagName] = Element.extend(document.createElement(tagName));
    return Element.writeAttribute(cache[tagName].cloneNode(false), attributes);
  };
  Object.extend(this.Element, element || { });
}).call(window);

Element.cache = { };

Event.extend - Don't do It!

The same approach is used here

Event.extend = (function() {
  var methods = Object.keys(Event.Methods).inject({ }, function(m, name) {
    m[name] = Event.Methods[name].methodize();
    return m;
  });

  if (Prototype.Browser.IE) {
    Object.extend(methods, {
      stopPropagation: function() { this.cancelBubble = true },
      preventDefault:  function() { this.returnValue = false },
      inspect: function() { return "[object Event]" }
    });

    return function(event) {
      if (!event) return false;
      if (event._extendedByPrototype) return event;

      event._extendedByPrototype = Prototype.emptyFunction;
      var pointer = Event.pointer(event);
      Object.extend(event, {
        target: event.srcElement,
        relatedTarget: Event.relatedTarget(event),
        pageX:  pointer.x,
        pageY:  pointer.y
      });
      return Object.extend(event, methods);
    };

  } else {
  // (GS) Event.prototype is not guaranteed to be available in 
  // any browser.
    Event.prototype = Event.prototype || document.createEvent("HTMLEvents").__proto__;
    Object.extend(Event.prototype, methods);
    return Prototype.K;
  }
})();

Object.extend - Doesn't Account for JScript DontEnum Bug

Object.extend = function(destination, source) {
  for (var property in source)
// (GS) Does not account for JScript DontEnum bug.
    destination[property] = source[property];
  return destination;
};

In IE, the keys of objects are skipped without properly checking the DontEnum flag. The skipped properties include the useful and often overridden toString and valueOf. Special and careful considerations should be made to address this problem.

$A - Don't Rely on The Return Value of An Object's toString

if (Prototype.Browser.WebKit) {
  $A = function(iterable) {
    if (!iterable) return [];
// (GS) Do not on the return value of an object's toString.
    if (!(Object.isFunction(iterable) && iterable == '[object NodeList]') &&
        iterable.toArray) return iterable.toArray();
    var length = iterable.length || 0, results = new Array(length);
    while (length--) results[length] = iterable[length];
    return results;
  };
}

A toString() with the return value of "[object NodeList]" implies nothing else about the object it was called on.

The readAttribute function, branched for Internet Explorer.

Example

Example page: http://www.apple.com/itunes/

javascript:alert($(document.body).readAttribute("onload"))

Will result in partial string representation of a serialized function. The string begins with ")".

_getEv: function(element, attribute) {
// (GS) Do not rely on function decompilation.
  var attribute = element.getAttribute(attribute);
// (GS) Do not prevent yourself from renaming a function.
// (GS) Broken - slice starts at wrong position.
  return attribute ? attribute.toString().slice(23, -2) : null;
},

Function readAttribute calls getAttribute on the element. In Internet Explorer, calling getAttribute always reflects the property with the same name. In this case the property has the value of the function object, loadShortcuts.

It isn't clear why the substring of 23 should be taken from the function's source code. The approach of relying on the toString of an object defined elsewhere in the code makes it hard to rename that function.

Ajax.Request - Add an Underscore?

  request: function(url) {
    this.url = url;
    this.method = this.options.method;
    var params = Object.clone(this.options.parameters);

    if (!['get', 'post'].include(this.method)) {
      // simulate other verbs over post
      params['_method'] = this.method;
      this.method = 'post';
    }

    this.parameters = params;

    if (params = Object.toQueryString(params)) {
      // when GET, append parameters to URL
      if (this.method == 'get')
        this.url += (this.url.include('?') ? '&' : '?') + params;

// (GS) All browsers support properly-formatted URIs.
// (GS) Do not add extra "_" parameter for some browsers.
      else if (/Konqueror|Safari|KHTML/.test(navigator.userAgent))
        params += '&_=';
    }

Broken Unescaping of HTML Strings

PrototypeJS adds escapeHTML and unescapeHTML to String.prototype. The problem with this code was discussed quite some time ago on comp.lang.javascript.

if (Prototype.Browser.WebKit || Prototype.Browser.IE) Object.extend(String.prototype, {
  escapeHTML: function() {
    return this.replace(/&/g,'&amp;').replace(/</g,'&lt;').replace(/>/g,'&gt;');
  },
  unescapeHTML: function() {
    return this.replace(/&amp;/g,'&').replace(/&lt;/g,'<').replace(/&gt;/g,'>');
  }
});

// (GS) Do not use with for simple property assignment
with (String.prototype.escapeHTML) div.appendChild(text);

The problem is that the escape character for entities is &. This will have the result in browsers identifying as Webkit or MSIE of:-

    "&amp;lt;".unescapeHTML() to "<" 

The with statement is not needed to provide a more compact approach:

"".escapeHTML.div.appendChild("".escapeHTML.text);

Enumerable.include - Two Loops? Strict Equality, or Loose Equality?

Enumerable.include. This function returns true if the Enumerable contains the object.

  include: function(object) {

    // (GS) Call the indexOf method on the object.
    if (Object.isFunction(this.indexOf))
      if (this.indexOf(object) != -1) return true;
    // (GS) If not found, search again.
    var found = false;
    this.each(function(value) {
    // (GS) Should use strict equality, === 
      if (value == object) {
        found = true;
        throw $break;
      }
    });
    return found;
  },

Enumerable.include first calls this.indexOf(), and if that returns false, the collection is searched using a similar algorithm to Array.prototype.indexOf, except not using strict equality. This tactic results in the collection being looped over twice. Function each calls a function for each iteration. If non-strict equality is desired, then the strict equality check that can result by calling this.indexOf should be omitted.

A plausible solution would be return this.indexOf(object), and include a strict === check if indexOf were not a function.

getDimensions - clientWidth != offsetWidth, And Don't Expect clientWidth to be non-zero in IE

  getDimensions: function(element) {
    element = $(element);
    var display = $(element).getStyle('display');
    if (display != 'none' && display != null) // Safari bug
      return {width: element.offsetWidth, height: element.offsetHeight};

    // All *Width and *Height properties give 0 on elements with display none,
    // so enable the element temporarily
    var els = element.style;
    var originalVisibility = els.visibility;
    var originalPosition = els.position;
    var originalDisplay = els.display;
    els.visibility = 'hidden';
    els.position = 'absolute';
    els.display = 'block';
    var originalWidth = element.clientWidth;
    var originalHeight = element.clientHeight;
    els.display = originalDisplay;
    els.position = originalPosition;
    els.visibility = originalVisibility;
// (GS) use offsetWidth/Height.
    return {width: originalWidth, height: originalHeight};
  },

This method has the unique quality of being one of the only methods in PrototypeJS to have a code comment.

The code tries to get the offsetWidth and offsetHeight of the Element. If the element is not displayed, then these properties will be 0, and in that case, the function will display the element temporarily, then calculate its clientWidth - not the offsetWidth before immediately hiding it. This function can be expected to provide inconsistent results when the element's CSS display is changing. What's worse: Unless the element has a CSS width, the clientWidth will be 0 in IE.

Calculating Offsets

Finding an Element's position is hard.

Calculating the position of an element requires adding the offsetTop/Left of offsetParents, border offsets, and scroll offsets of parentNodes.

A BODY with margin, position and/or border can affect the offsetTop/Left differently, depending on the browser. This is a harmful effect propagated by the CSSOM Views standard.

cumulativeOffset

PrototypeJS misses both points and just adds offsetTop/Left.

  cumulativeOffset: function(element) {
    var valueT = 0, valueL = 0;
    do {
      valueT += element.offsetTop  || 0;
      valueL += element.offsetLeft || 0;
      element = element.offsetParent;
    } while (element);
    // (GS) Don't call a function that returns an 
    // Array with top and left properties.
    // Better just return an Array or an Object.
    return Element._returnOffset(valueL, valueT);
  },

The seriousness of the problem is apparent when precision is crucial and off by a pixel or more would be failure, (e.g. make element to overlap another element exactly, activate a drop zone).

The bug also exists in positionedOffset and affects every function that uses either function, including within, scrollTo, and all the functions that call those functions, such as others found in Scriptaculous (dragdrop.js, effects.js).

Conclusion

A few core parts of PrototypeJS exhibiting some serious bugs. There are many more issues, such as Hash, but this entry is already getting excessively long.

PrototypeJS is designed in a non-standard way around the modification of host objects. The code that exists is complicated and not very efficient. I cannot recommend using this library for anything.

Technorati Tags: JavaScript Code Review Prototype Prototype.js

I came across a blog post yesterday that had a lot of misinformation. The post had received several comments and trackbacks thanking and commending the author for his "helpful" post. At first I was mad. "How can these people give this guy credit for misinformation," I thought. I wrote up a comment correcting on various points, intending to publish it on the author's blog.

Thankfully, my comment could not be posted due to some problem with the weblog. I am thankful of this because I ended up thinking about the problem on a greater depth.

I decided to respond here, providing a review below. I was more bothered by the phenomenon of people eager to learn misinformation. The more I thought about that phenomenon, the more I realized that it's not the author's fault, it's just the way things are. I discovered a part of the web that I want to change.

The expert, in this case, is Alex Russell, of Dojo fame, as Ajaxian likes to call it. It doesn't really matter who it is. In fact, it could have been me several years ago, when my JavaScript knowlegde was not as strong. I have written some really awful javascript that fortunately did not become famous.

My initial technical responses to the blog entry, which I have cut and snipped, are interspersed below. I have done my best to not take the author out of context and provide clear, relevant feedback. My real "response" starts below the proceeding technical response.

Technical Response

alex:

Everything in JavaScript is an Object. Even functions

Not true.

Fact: There are primitive values, too: undefined, null, true, 3, and "foo" are all primitive values. Not objects.

alex:

Every object is always mutable

Fact: An EcmaScript object itself is always mutable, but property-setting will not be always successful and error-free.

1. Host objects do not need to implement setters for each property. For purpose of providing a relevant example to back up my claim:

   function fixEvent(e) {
     e=e||event;
     e.pageX = 1; // getEventPageX(e);
   }

   - will cause an error in Firefox. The pageX property actually needs a patch, because creating events, the pageX property doesn't get set correctly (bug 411031). So the argument "every object is always mutable" leads to developers doing things like writing a "fixEvent" function. It is not safe to do so.

2. Some properties are tagged ReadOnly. A String or Function object's length property, for example.

alex:

The dot operator is equivalent to de-referencing by hash (e.g., foo.bar === foo["bar"])

Fact: The two property access operators .<Identifier> and [<identifier-string>] perform identical operations.

alex:

The new keyword creates an object that class constructors run inside of, thereby imprinting them

False.

Fact: There are no class constructors. No classes in the current release of EcmaScript 262 r3.

The new operator (an operator) creates a new object in context of the function on which its called. Nothing gets imprinted.

alex:

Functions are always closures (combine w/ previous rule to create OOP)

If used very carefully, closures can be used to mimic some of the constructs found in OO languages. However, to say that closures "create OOP" is false and misleading.

alex:

The this keyword is relative to the execution context, not the declaration context

There is no "declaration context". You seem to have made this up as a way to describe the way you think JavaScript works.

alex:

The prototype property is mutable

Not informative.

Fact: A property is a reference.

If the property's value is a native EcmaScript object, then it will be mutable. It goes without saying that this is true even if the name of the property is prototype.

Considering a prototype property of a function, where the prototype's value is an EcmaScript object: {}, then it is mutable (as discussed above).

alex:

Jeremy: great clarifications. Thanks.

Jeremey provided a false statement with code that was confusing. Jeremey wrote:

y = new Foo();
assert(y.gimme() == 2);

But:

button.onclick = "alert(y.gimme())" will error rather than alerting "2", because in an event handler, "this" refers to the elm which sourced the event.

Fact: This is a perfectly valid assignment of a string value to an onclick property of a button object.

Jeremy's example of a button object with an onclick property assigned to a string value:-

button.onclick = "alert(y.gimme())"

- the string "alert(y.gimme())" is not eval'd.

(Continuing Jeremy's post)

because in an event handler, "this" refers to the elm which sourced the event.

Has relevant meaning in a script:-

// assign function to onclick.
button.onclick = y.gimme;

Definitely not in:

<body>
<script>

function Foo() {
this.x = 1;

this.gimme = function() {
return this.x + 1;
}
}

y = new Foo();
</script>

<button onclick="alert(y.gimme())">click me</button>

</body>

Result

When the button is clicked, the method gimme is called with y as the thisArg. The number is returned and displayed as a string in the alert box.

Thanking Jeremy for Jeremy's mistake and calling the mistake a clarification does not make Jeremy correct. It is not helpful to Jeremy or anyone else.

alex: (To Dethe):

My statement about objects (variables whose .constructor property in some way descends from Object) was correct.

Fact: No, it was not correct. Now you've made another misstatement.

Fact: (new function(){}) - is an object, not a variable. Its - constructor - property doesn't "descend" from Object, either.

Fact: var i = 0, len; - is an example of two variables that do not have a .constructor property.

Fact: The term "descend" has no meaning in context of describing a constructor property; it is fictitious terminology to describe the way you imagine JavaScript works.

(alex: To Dethe, continued):

Also, the hash deference is exactly equivalent. That there's no way to have a JS lexer handle an variable name with spaces in it in no way detracts from the equivalence, it just means that the dot operator has to follow the rules of thing that aren't string literals.

Fact: There is no "dot operator."

Fact: The fullstop, "." also has meaning in numbers, for example, 4.2.toString().

Fact: There are two property access operators: "." and "[]". There are many "things that are not string literals." The "." property access operator can be used only for valid identifiers.

I think you were using the term "de-reference" to try to describe getting a value. Now your using "deference". I'm not sure what to make of that.

The Real "Response"

My real "response" in the larger sense, is that I'm taking a stance. I'm going to try and change the web.

Think 2.0

A who's-who in web 2.0 is destructive to the web, in a way. The idea should win, not the individual. The popular libraries have spread ideas for web development across the web but they have also played a big part in the "whos-who" trend that I see.

What I see demonstrated in the blog entry that I replied to is a misunderstaning of JavaScript that received positive acknowledgement and review. The question is: Why? Is it because the entry is simple and clear?

Ask Why

If a "famed" individual can be commended for teaching JavaScript facts that are false and inaccurate, what does that say about what web developers value in the web? Where are we headed? I am hoping that this trend will reverse itself. The reversal of this trend starts by questioning things. I question things and you should, too.

Angry, Bitter, and Vile?

As much as I've pointed out bad parts of Dojo and Google (And jQuery and PrototypeJS and YUI), I probably sound like a bitter, angry person. In fact, there are people who would love to have you believe that I am nothing more than that. I've made my observations and shared them, even at the expense of sounding mean and bitter. I want the web to change, and in my next entry, I'll clearly explain the direction I want the web to turn.

Technorati Tags: JavaScript