NCZOnline http://www.nczonline.net/blog The Official Web Site of Nicholas C. Zakas Wed, 17 Mar 2010 00:00:08 +0000 http://wordpress.org/?v=2.6.1 en Empty-string URLs in HTML - A followup http://feedproxy.google.com/~r/nczonline/~3/sqz1HleFSHk/ http://www.nczonline.net/blog/2010/03/16/empty-string-urls-in-html-a-followup/#comments Tue, 16 Mar 2010 13:00:09 +0000 Nicholas C. Zakas http://www.nczonline.net/blog/?p=2433 Late last year, after spending 10 days tracking down a horrific bug, I posted, Empty image src can destroy your site. The post laid out a problem present in almost all modern browsers regarding empty string URLs in HTML. Empty-string URLs look like this:

<img src="">
<script src="">
<link rel="stylesheet" href="">

Depending on the browser, one or more of these elements will actually cause another request to the server. Not just any request, though, a request to the containing page. That means the entire markup of your page is regenerated and served even though no one is actually viewing it. The linked post explains in detail why this is problematic, but suffice to say, these type of unexpected requests to your server can bring down high-traffic sites by unexpected increasing traffic or alternately can corrupt user state information.

Current state of browsers

As a quick summary of where we are today, here’s how the various browsers stock up:

  • Internet Explorer through version 8 make a request for <img src=""> only.
  • Firefox 3 and earlier makes a request for all three of the patterns.
  • Firefox 3.5 fixed the <img src="'> case but not the others.
  • Safari 4 makes a request for all three patterns.
  • Chrome 4 makes a request for all three patterns.
  • Opera doesn’t make a request in any of these instances.

It’s not a pretty picture out there. But there has been movement since my last post.

Forward progress

Believing that this was the wrong behavior, I began contacting various browser vendors to ask if this behavior could be addressed. The most frequent response I received was that the browser was “following the standards” and shouldn’t be changed. I thought this was too dismissive and did some digging. The inconsistent treatment of empty-string URLs even within a single browser led me to believe that there was no specification governing this behavior. As it turned out, the specification to which everyone was referring was the URL specification (RFC 3986 - Uniform Resource Identifiers) and not HTML. While the URL specification does indicate that resolution for an empty string should result in the containing page, my argument was that this made no sense in the context of HTML.

HTML5

So in December, I posted a message to the WHAT-WG mailing list to see if I could get some consensus on this issue. After a lengthy discussion and a bunch of research, everyone ended up agreeing that this behavior was unexpected and should be changed. This month, changes were made to HTML5 specifically stating that empty-string URLs should not cause server requests for the following (complete diff):

<img src="">
<input type="image" src="">
<script src="">
<link rel="stylesheet" href="">
<embed src="">
<object data="">
<iframe src="">
<video src="">
<video poster="">
<audio src="">
<command icon="">
<html manifest="">
<source src="">

Essentially, any tag that would result in the automatic download of an external resource will not make such a request if an empty-string URL is specified.

Thusfar, the Firefox team has agreed to make this update (see bug 531327). I filed a bug with the Chromium team (issue 38144) and also commented on a bug that was already filed at WebKit (bug 30303) and am waiting for updates (if a WebKit contributor would like to take this on, please do). Perhaps not surprisingly, I’ve had a little trouble pleading my case to Microsoft. I’ve not given up, but if you are or have a Microsoft contact that could help resolve this issue, please let me know.

YSlow

Since the empty-string URL issue really affects server performance, I asked the YSlow team if they could add in empty-string URL detection. Even though the issue with empty image URLs has been resolved in Firefox, it’s still present in other browsers, so YSlow’s flagging of this serious issue can help you avoid problems in other browsers.

In this initial release with the feature, there is a new non-default rule that you can turn on in a custom ruleset. To do so, click the Edit button next to the list of rulesets, check the box next to “Avoid empty src or href”. Click “Save ruleset as…” and type in a new name. Then, select your new ruleset from the dropdown box and click the “Run Test” button.

New YSlow rule for empty href or src

This new rule is under the “Server” group of rules. YSlow will correctly detect <img src=""> and <link rel="stylesheet" href=""> and give you an F if there are any instances of either of these patterns.

New YSlow rule for empty href or src

Note that due to a bug in YSlow, you’ll sometimes also get an A for this rule even if you do have one of the offending patterns present. This will be addressed soon.

Thanks

Things sometimes seem to move slowly on the Internet, but ultimately I believe things tend to get done correctly. We’re still likely at least a year away from never needing to worry about this issue again, and for that I need to thank a bunch of people:

  • Jonas Sicking of Mozilla for suggesting that this issue be brought up on the WHAT-WG mailing list and for participating in the discussion.
  • Simon Pieters of Opera and Maciej Stachowiak of WebKit for chiming in and agreeing that this behavior seemed broken.
  • Ian Hickson for making the adjustments in HTML5 so that this issue can be put to rest.
  • Stoyan Stefanov and the YSlow team for adding empty-string URL detection to YSlow.

Related posts

P.S. My new book, High Performance JavaScript is coming out in early 2010. Need help now? Check out Professional JavaScript, 2nd Edition.

]]> http://www.nczonline.net/blog/2010/03/16/empty-string-urls-in-html-a-followup/feed/ http://www.nczonline.net/blog/2010/03/16/empty-string-urls-in-html-a-followup/ Custom events in JavaScript http://feedproxy.google.com/~r/nczonline/~3/Oe0fKOWnDCY/ http://www.nczonline.net/blog/2010/03/09/custom-events-in-javascript/#comments Tue, 09 Mar 2010 13:00:53 +0000 Nicholas C. Zakas http://www.nczonline.net/blog/?p=2429 Without a doubt, the most often-used paradigm in JavaScript is events. Events are a manifestation of the observer pattern, a well-defined computer science design pattern for loose coupling. Loose coupling is incredibly important for creating maintainable, stable codebases. I talk a lot about loose coupling and its importance in my talk, Scalable JavaScript Application Architecture (video), so I won’t talk too much about it here. However, the concept is very important to grasp if you wish to progress as a software engineer.

Events

Unless you’ve never written any JavaScript before, you’ve used events at some point in time (admittedly, if you’ve never written JavaScript before, the chances of your reading my blog are probably pretty slim). Put quite simply: the way that you tie behavior to web pages is through events. Events are a way of letting interested parties know that an important moment has occurred in the lifecycle of the application. For instance:

window.onload = function(){
    Application.init();
};

In this example, the load event is the interesting moment. I want to know when the window is fully loaded so that I can initialized the JavaScript application. The onload event handler is the location to where an event handler is assigned. The brilliant part is that window doesn’t care what web page is loaded or who is writing the code; it just knows that there’s a function to call when load occurs. This is the essence of loose coupling: when parts of an application have very limited knowledge of one another.

The Browser Object Model (BOM) and Document Object Model (DOM) publish events to allow developers access to the interesting moments of the browser and web page, respectively.

Custom events

It’s no surprise that most JavaScript libraries rely heavily on custom events since this is a pattern that web developers are familiar with. Every major JavaScript library provides its own events, components to enable easy custom event definition, or both. This makes sense, of course, since libraries want to be loosely-coupled to the execution environment, and therefore, to your code.

There’s nothing magic about custom events, though, and there’s no need to load an entire library if you’d like to experiment with custom events. An object that supports custom events needs to be able to do a small set of things:

  1. Assign an event handler for a particular event.
  2. Remove an event handler for a particular event.
  3. Fire an event and call all assigned event handlers.

The following implements all of this basic functionality:

//Copyright (c) 2010 Nicholas C. Zakas. All rights reserved.
//MIT License

function EventTarget(){
    this._listeners = {};
}

EventTarget.prototype = {

    constructor: EventTarget,

    addListener: function(type, listener){
        if (typeof this._listeners[type] == "undefined"){
            this._listeners[type] = [];
        }

        this._listeners[type].push(listener);
    },

    fire: function(event){
        if (typeof event == "string"){
            event = { type: event };
        }
        if (!event.target){
            event.target = this;
        }

        if (!event.type){  //falsy
            throw new Error("Event object missing 'type' property.");
        }

        if (this._listeners[event.type] instanceof Array){
            var listeners = this._listeners[event.type];
            for (var i=0, len=listeners.length; i < len; i++){
                listeners[i].call(this, event);
            }
        }
    },

    removeListener: function(type, listener){
        if (this._listeners[type] instanceof Array){
            var listeners = this._listeners[type];
            for (var i=0, len=listeners.length; i < len; i++){
                if (listeners[i] === listener){
                    listeners.splice(i, 1);
                    break;
                }
            }
        }
    }
};

The EventTarget type has three methods: addListener(), fire(), and removeListener.

The addListener() uses the private _listeners object to store event handlers for various events. When an event handler is added, the method first checks to see if there’s a named property for that event type on the _listeners object, and if not, creates one containing an array. The event handler function is then saved to the array for later.

The fire() method fires an event with a given name. In effect, this method’s only job is to execute each event handler for the given event type. The method accepts either an object, in which case it’s expected to have a type property, or a string, in which case a new object is created and the string is assigned as the value of type. Next, if the event object doesn’t have a target property assigned, it is set to the current instance. This effectively creates an event object similar to the one most are familiar with via the BOM and DOM. Once the event object is created, the _listeners object is checked for event handlers, and if found, they are executed. Note that in order to mimic the BOM/DOM approach, event handlers are executed in the scope of this via the call() method.

The last method, removeListener(), simply reverses the process of addListener(). It searches through the _listeners property for the given event type to locate the specified event handler. If found, the event handler is removed by using the array’s splice() method, and otherwise it exits without doing anything.

Basic usage:

var target = new EventTarget();
function handleEvent(event){
    alert(event.type);
};

target.addListener("foo", handleEvent);
target.fire({ type: "foo" });    //can also do target.fire("foo")
target.removeListener("foo", handleEvent);

Practically speaking, you’ll likely not want to use an instance of EventTarget directly, but rather inherit from it:

function MyObject(){
    EventTarget.call(this);
}

MyObject.prototype = new EventTarget();
MyObject.prototype.constructor = MyObject;
MyObject.prototype.foo = function(){
    this.fire("foo");
};

var o = new MyObject();

o.addListener("foo", function(){
    alert("Foo just happened.");
});

o.foo();

Typically, events are fired in reaction to some other method call, as in this example (events are usually not fired external to the object that is publishing the events).

What about…?

This is a pretty barebones implementation of a custom event providing object, so inevitably someone will come along and ask why I didn’t include one feature or another. There are, of course, a lot of enhancements you can make to custom events if you so desire. Some enhancements others have implemented:

  • Bubbling of events
  • Continue to execute event handlers even if one throws an error
  • Allow event handlers to cancel further processing or default actions

Each of these can be built pretty easily on top of the base presented in this post.

Conclusion

Custom events are a very powerful and useful pattern in JavaScript programming, and your usage of them doesn’t have to rely on a large JavaScript library. Implementing your own custom events is easy. The implementation presented in this post is a minimum feature set that typically fulfills most requirements, but you can consider it as a starting point for more advanced functionality if your requirements are more complex.

Related posts

P.S. My new book, High Performance JavaScript is coming out in early 2010. Need help now? Check out Professional JavaScript, 2nd Edition.

]]> http://www.nczonline.net/blog/2010/03/09/custom-events-in-javascript/feed/ http://www.nczonline.net/blog/2010/03/09/custom-events-in-javascript/ Maintainable JavaScript: Don’t modify objects you don’t own http://feedproxy.google.com/~r/nczonline/~3/8Gd-HPtkAoU/ http://www.nczonline.net/blog/2010/03/02/maintainable-javascript-dont-modify-objects-you-down-own/#comments Tue, 02 Mar 2010 13:00:07 +0000 Nicholas C. Zakas http://www.nczonline.net/blog/?p=2422 The first talk I gave after arriving at Yahoo! was entitled Maintainable JavaScript (video). As with most topics I write or speak about, I didn’t think it would be terribly controversial. The basis of the talk is that hacking around on your own and writing code in an enterprise environment are two different things. Web developers are truly unique in that none of us learned what we know in school; we all began as hobbyists one way or another and taught ourselves most (if not all) of what we know.

Professionalization

The professionalization of web development has been a difficult journey because of our disparate beginnings. Even those who end up at large companies such as Yahoo! inevitably began on their own, hacking around. Perhaps you were even “the web guy” at a small company and could do pretty much whatever you wanted. When the large companies started tapping this previously undiscovered resource, it brought a lot of hackers into a corporate environment where they were met with constraints. No longer a lone soldier in a small battle, all of these self-taught, self-directed individuals had to figure out how to work together as a team.

At the time that I gave the talk (2007), web development was evolving into front-end engineering and people were having trouble with the transition. Smart folks like Nate Koechley talked about the professionalization of front-end engineering (video) and how our discipline was evolving. My talk was aimed at the same goal: helping front-end engineers adapt to JavaScript development in a team environment by making sure that their code was as maintainable as possible.

Why can’t I modify objects I don’t own?

I still gets email and comments about Maintainable JavaScript, and the most popular question is, “why can’t I modify objects I don’t own?” JavaScript is, of course, a dynamic language that allows you to add and remove objects and their members at any point in time. For many, this is precisely why they enjoy the language: there are very few constraints imposed by the language. And I was telling them not to do this. Why?

Dependability

The simple explanation is that an enterprise software product needs a consistent and dependable execution environment to be maintainable. In other languages, you consider already-existing objects as libraries for you to use in order to complete your task. In JavaScript, people saw already-existing objects as a playground in which you could do anything you wanted. My point was that you should treat the already-existing JavaScript objects as you would a library of utilities. Don’t override methods, don’t add new methods, don’t remove existing methods.

When you’re the only one working on a project, it’s easy to get away with these types of modifications because you know them and expect them. When working with a team on a large project, making changes like this cause mass confusion and a lot of lost time. I still remember a bug that occurred while working on My Yahoo! because someone had overridden YAHOO.util.Event.stopEvent() to do something else. It took days to track this problem down because we all assumed that this method was doing exactly what it always did. Once we discovered this, we also found other bugs because the same method was being used in other places with its original intended usage…but of course, it wasn’t behaving in that way. Unraveling this was an incredible mess and I’d be very happy if no engineers ever had to go through a similar exercise.

Incompatible implementations

But developer confusion isn’t the only problem. Another peril of modifying objects that you don’t own is the possibility of naming collisions and incompatible implementations. Take a lesson from the history of the Prototype JavaScript library. John Resig wrote about this a while ago, so I’ll just quickly summarize. Prior to version 1.6, Prototype implemented its own document.getElementsByClassName() method long before it was part of HTML5 and long before any browser thought about implementing it natively. In addition, Prototype also added the each() method to Array objects. Thus, users of the Prototype library began writing code such as:

document.getElementsByClassName("myclass").each(doSomething);

This wasn’t a problem until the native document.getElementsByClassName() method was implemented. While Prototype’s version returned an instance of Array, the native implementation returns a NodeList object. Since NodeList doesn’t have an each() method, either natively or added by Prototype, the above coding pattern caused a JavaScript error when executed in browsers that had a native implementation of document.getElementsByClassName(). The end result is that users of Prototype had to upgrade both the library code and their own code; what a maintenance nightmare.

What if everyone did it?

Looking at a few isolated examples doesn’t really represent the enormity of the maintenance problem when you modify objects that you shouldn’t. To understand this point of view, it’s helpful to take a step back and look at moral philosophy (aka ethics). Moral philosophy is all about determining if an action is moral. There are many schools of thought on the topic, but I point towards a favorite modern philosopher, Immanuel Kant.

While I don’t want to get too deeply into moral philosophy and open this up for philosophical debate, Kant was famous for trying to determine “universal law” as the basis for moral action. In short, you can determine if an act is moral by asking, what would happen if everyone did it? For example, what if everyone cheated on a test? In that case, the test becomes useless, so this must not be a moral action.

Applying this same line of reasoning to the topic at hand, what if everyone on your team started modifying objects that they didn’t own? What if I went in and made modifications to document and so did everyone else on my team? What if everyone on the team created their own global variables? I hope that it’s obvious just how detrimental these actions could be to a team development environment.

Simply put: if everyone on your team modified objects that they didn’t own, you’d quickly run into naming collisions, incompatible implementations, and maintenance nightmares.

As a side note, I find Kant’s question incredibly relevant to any system that must scale. “What if everyone did it?” can really save you some trouble when considered as part of a technical design.

Conclusion

Maintainable code is code that you don’t need to modify when the browser changes. You don’t know how browser developers will evolve existing browsers and the rate at which those evolutions will take place. The code you write needs to continue working in future browsers and with future versions of JavaScript libraries without modification, and you cannot ensure that when you’re modifying objects that you didn’t create in the first place. The only code you can be certain will remain the same is the code you write yourself.

I can’t state this strongly enough: your code is not maintainable when it requires modifications to objects you didn’t create. Stepping down that path only leads to maintenance nightmares going forward.

P.S. If you’re interested in learning more, check out my presentation on Scalable JavaScript Application Architecture (video).

Related posts

P.S. My new book, High Performance JavaScript is coming out in early 2010. Need help now? Check out Professional JavaScript, 2nd Edition.

]]> http://www.nczonline.net/blog/2010/03/02/maintainable-javascript-dont-modify-objects-you-down-own/feed/ http://www.nczonline.net/blog/2010/03/02/maintainable-javascript-dont-modify-objects-you-down-own/ Answering Soshnikov’s quiz http://feedproxy.google.com/~r/nczonline/~3/TMtQ6FN5KiA/ http://www.nczonline.net/blog/2010/02/23/answering-soshnikovs-quiz/#comments Tue, 23 Feb 2010 13:00:23 +0000 Nicholas C. Zakas http://www.nczonline.net/blog/?p=2413 JavaScript quizzes have sure been popular lately. The latest addition is one by Dmitry A. Soshnikov and is affectionately called, The quiz. I must admit, this quiz has some of the most mind-bending examples of JavaScript I’ve ever seen. What I like about his quiz is that each piece of code is more or less reliant on a single JavaScript concept, and that’s why I’m spending another week explaining another quiz.

Question #1

typeof typeof(null)

This is probably the easiest of all of the questions. Whenever you have typeof typeof, the result is always “string”. Why? Because the typeof operator always returns a string value (in this case, it returns “object” for typeof(null)).

Question #2

Are the algorithms of the following checks completely equivalent?

typeof foo == 'undefined'

and

typeof foo === 'undefined'

The quiz claims that the answer is “yes”, though as Kangax pointed out, the algorithms for these two operations are actually different. A better way to ask this question would have been, “is the end result of these two checks completely equivalent?” The answer to that is a definitive yes because you’re ultimately comparing two strings in each comparison. When comparing two strings, the == operator doesn’t do any type coercion and so the two comparisons will always return the same result.

Question #3

What’s the result of:

100['toString']['length']

A couple of good pieces of deception in this one. Numbers end up wrapped by the Number type when you use them, and the Number type has a toString() method. However, you’re not actually calling toString() in this case, you’re actually accessing the length property of the toString() method. It makes more sense to look at the code like this:

100.toString.length

The length property of a function indicates how many names arguments are expected. The toString() methods accepts one argument, which is the radix in which to output the string representation of the number (for example toString(2) outputs the binary representation of the number as a string and toString(16) outputs the hexadecimal representation of the number as a string).

So the answer to this question is 1.

Question #4

What’s the result of:

var a = (1,5 - 1) * 2

This is the first question that relies on your knowledge of how the comma operator works. To put it simply: when there’s an expression containing one or more commas, the value of the expression is equal to the last value. For example, the value of (1,2,3,4) is 4 and the value of ("hello", "world") is “world”. The comma operator’s best use is in defining multiple variables and the example usage here is definitely not recommended.

Given this knowledge, it should be obvious that the answer to this question is 8. That’s because (1,5-1) gets evaluated to (1,4) so the final value is 4. I’m sure you can take it from there.

Question #5

What’s the result of:

var x = 10;
var foo = {
  x: 20,
  bar: function () {
    var x = 30;
    return this.x;
  }
};

console.log(
  foo.bar(),
  (foo.bar)(),
  (foo.bar = foo.bar)(),
  (foo.bar, foo.bar)()
);

This code outputs four values onto the console. The real question is what are the four values. It should be very obvious that the first value is 20 because foo.bar() accesses this.x on foo, which is 20. The next part, (foo.bar)() acts in the exact same way as foo.bar(). Wrapping foo.bar in parens doesn’t change how it’s evaluated. This also outputs 20.

The tricky part comes next. The return value of an assignment expression is always the right-hand side expression. Assigning a function to a location, even if it’s the same location from where it came, results in the overall expression having a value of the function. The important piece of information is that the function now has no context object associated with it, so (foo.bar = foo.bar)() executes as if it where foo.bar.call(). Of course, any function called outside of an object context gets executed in the context of the global, so this.x now is 10. Thus, the third part outputs 10.

The fourth variation outputs the same result as the third. Once again you encounter the comma operator. Keep in mind that foo.bar in this part of the code represents a pointer to the function, and the comma operator takes on the value of that function before being called. This outputs the same value as the previous section for the same reason: using the comma operator means the function is context-free and gets executed in the global scope.

So your overall answer: 20 20 10 10.

Question #6

What’s the result of:

function f(x, y) {
  x = 10;
  console.log(
    arguments[0],
    arguments[1]
  );
}

f();

This function has two named arguments but neither are provided when the function is called. You should know that the value of these named arguments will be undefined in this case, and so outputting arguments[1] should also obviously be undefined. The only question, then, is the value of arguments[0]. This actually tests the inverse of what Baranovskiy’s fourth question tested. In his test, Barnovskiy changed a value in the arguments object and you saw that the corresponding named argument changed in value as well (see my writeup for more info). The opposite, however, is not true.

Changing the named argument’s value does not automatically change the corresponding value in arguments. As mentioned in my aforementioned post, the arguments object and the named argument do not share memory space. When a change is made to arguments, that value is copied to the named argument. It doesn’t work the other way. A named argument is no more special than a local variable, and so changing its value doesn’t affect the arguments object. So, arguments[0] is still undefined and the output of the code is undefined undefined.

Question #7

What’s the result of:

var
  b = 10,
  c = (
    20,
    function (x) { return x + 100},
    function () { return arguments[0]}
  );

a = b + c
({x: 10}).x

There are only two concepts that you need to understand to answer this. The first is how the comma operator works, which you should be an expert in by now. The value of c is the function function(){ return arguments[0];}, which just returns the first argument that was passed in.

The second thing you need to know is how automatic semicolon insertion works. Because of the way the code is formatted, you might be inclined to believe that a semicolon will be inserted after a = b + c. Keep in mind that c is a function, and the next non-whitespace character is (. In this case, the whitespace is ignored, so the last line is actually:

a = b + c({x: 10}).x

Since the function contained in c simply passes back the argument that was passed in, the result of this expression is logically equivalent to:

a = b + ({x: 10}).x

And that is really just:

a = b + 10

This makes a equal to 20, and that is the final value of the code.

Question #8

What’s the result of:

1..z

Another sneaky question. At first glance, this looks like an obvious syntax error. However, there is no syntax error here because of the way this text is parsed. Remember from earlier that numbers end up wrapped by the Number type when accessed, which makes an ad-hoc object. The z in this case is attempting to access a property, which means the code could be written as:

(1.)["z"]

So what is 1.? It’s actually a valid floating-point number in JavaScript. JavaScript unfortunately allows trailing decimal points on numbers, so you can have 1 or 1. or 1.0 depending on how you feel like writing the code. Trailing decimal points are considered bad practice and are a warning when code is run through JSLint.

Really, this question is asking you for the value of the property z on this number object representing 1.. Since there is no such property on Number objects, the value is undefined.

Question #9

What’s the result of:

({
  x: 10,
  foo: function () {
    function bar() {
      console.log(x);
      console.log(y);
      console.log(this.x);
    }
    with (this) {
      var x = 20;
      var y = 30;
      bar.call(this);
    }
  }
}).foo();

Another tricky one that tests your understanding of with statements. There’s really only one concept to grasp to get this question right, and that’s what var statements in with statements actually do. There are essentially three scenarios:

  1. The variable being declared doesn’t exist as a property on the context object (in this case, this) and the variable doesn’t exist as a local variable of the containing function (foo()). In this case, the variable declaration creates a new local variable to the containing function. This happens due to var statement hoisting (also described in my previous post).
  2. The variable being declared exists as a property on the context object. Two things actually happen here. First, the var statement is hoisted and a new local variable is defined. The initialization statement, however, stays in the same location and thus assigns the value to the object property with the same name.
  3. The variable being declared exists as a local variable of the containing function. In this case, the existing variable is simply assigned the given value.

Armed with this knowledge, you can determine the three values that are output. First, x is declared but never assigned a value. Due to var hoisting, the with statement is effectively the same as this:

var x;
var y;
with (this) {
    x = 20;
    y = 30;
    bar.call(this);
}

So var x = 20; gets mapped to this.x = 20; inside of the with statement since x exists as a property of the context object this. That means this.x changes from 10 to 20 while the local variable x is never assigned a value.

The function bar() is a closure inside of foo(), and therefore has access to all of foo()’s local variables (which are x and y). When console.log(x) is executed, it outputs undefined because the variable x was never initialized (all variables are assigned the value undefined when declared).

Next, y is assigned a value of 30, creating a local variable in foo(). Since bar() is a closure, it has access to all local variables of foo()y.

The last part, console.log(this.x); outputs 20 because the function is called in the context of the object.

So there’s your answer: undefined, 30, 20.

Question #10

What’s the result of:

foreach (k in {a: 10, b: 20})
{
  // ...
}

Another tricky one since foreach-in isn’t defined in ECMA-262. There is a for-each-in statement defined in ECMA-357 (ECMAScript for XML) and, in that spec, it is used to iterate over the values in an array. So the trick here is that knowing too much about JavaScript could actually lead to the wrong answer.

Since there is no foreach-in statement implemented anywhere, this should cause an error. You might think it would cause a syntax error but it won’t because foreach is a valid identifier (it’s not a keyword and follows the identifier format), so the JavaScript engine looks for a reference to foreach and, unable to find it, throws a ReferenceError.

The “correct” answer for this one is a point of contention. I would argue that the answer should “always ReferenceError” because if you run just this code in the example, this is what you get. The author says that the answer is actually “ReferenceError or possibly no error” because if foreach() and k are both defined previously, this won’t throw an error. Since all of the other questions hinge on just the code presented, I don’t think it’s a fair jump to ask people to make. However, to be as complete as possible, let’s assume the code is this:

function foreach(){
    //do something
}
var k = "a";

foreach (k in {a: 10, b: 20})
{
  // ...
}

With this code, you would receive no errors whatsoever. Why? Because foreach(k in {a: 10, b: 20}) evaluates to foreach(true) because the property “a” does exist in the given object literal. But what about the remaining curly braces?

This is another trick of automatic semicolon insertion. The format of the code looks like the braces represent the body of a statement, however, they actually represent an empty object literal. The code is interpreted as:

function foreach(){
    //do something
}
var k = "a";

foreach (k in {a: 10, b: 20});

{
  // ...
};

Note that a semicolon is inserted before the left curly brace and after the right curly brace. These are actually two separate and unrelated statements once the semicolons have been inserted. An object literal that isn’t assigned to a variable might look weird, but it’s still a valid statement, just like any of the following:

"hello world";
5;
true;

A statement doesn’t have to execute a function or assign a value, it may just contain a value.

Wrapping up

I really liked this quiz because of its high level of difficulty. Hopefully now you understand better how the comma operator works and some of the semantics around variable declaration hoisting.

Related posts

P.S. My new book, High Performance JavaScript is coming out in early 2010. Need help now? Check out Professional JavaScript, 2nd Edition.

]]> http://www.nczonline.net/blog/2010/02/23/answering-soshnikovs-quiz/feed/ http://www.nczonline.net/blog/2010/02/23/answering-soshnikovs-quiz/ My JavaScript quiz - answers http://feedproxy.google.com/~r/nczonline/~3/5_RmJCDU7gE/ http://www.nczonline.net/blog/2010/02/18/my-javascript-quiz-answers/#comments Thu, 18 Feb 2010 13:00:12 +0000 Nicholas C. Zakas http://www.nczonline.net/blog/?p=2404 Earlier this week, I posted my JavaScript quiz, containing some basic code along with questions. Here are the answers.

Example #1

var num1 = 5,
    num2 = 10,
    result = num1+++num2;

The key to understanding this example is to understand operator precedence. Clearly, +++ isn’t a valid operator, so the JavaScript engine breaks it up into a postfix increment operator and the plus sign. This code is completely valid and parses without problem, but really could be written like this:

var num1 = 5,
    num2 = 10,
    result = num1++ + num2;

With the understanding that this is how the code is interpreted, the questions should be fairly easy.

  • What is the value of result? The value is 15 because the postfix increment works after the num1+++num2 statement has executed.
  • What is the value of num1? The value is 6 because it is incremented after the last statement.
  • What is the value of num2? The value is 10 because no operation takes place on num2 itself.

Example #2

var x = 5,
    o = {
        x: 10,
        doIt: function doIt(){
            var x = 20;
            setTimeout(function(){
                alert(this.x);
            }, 10);
        }
    };
o.doIt();

The key to this example is understanding JavaScript scope. The alert inside of the closure references this.x, but because this reference is wrapped in a couple of functions inside of an object, what is the correct scope? The answer is pretty simple. All functions passed into setTimeout() are executed in the global scope.

  • What value is displayed in the alert? The value is 5 because this.x is the same as window.x and var x = 5 is equivalent to window.x = 5.

Example #3

var num1 = "10",
    num2 = "9";

The code is pretty self-explanatory, just two string variables being defined.

  • What is the value of num1 < num2? When both operands are strings, comparison operators perform string comparisons by comparing characters in the same position. The string “10″ comes before the string “9″ because the character “1″ comes before the character “9″ in ASCII. Since there are no more characters to compare after that point, this comparison is the one that remains. Thus, the value of num1 < num2 is true.
  • What is the value of +num1 < num2? The plus operator here converts num1 into a number, so now you’re comparing a number to a string. When this happens, the string operator gets converted into a number and then the comparison commences. So ultimately this is equivalent to 10 < 9, which very obviously is false.
  • What is the value of num1 + num2? Both operands are strings, which means a string concatenation happens. The result is "109".
  • What is the value of +num1 + num2? As you saw earlier, the plus operator converts a string to number, so num1 becomes the number 10. However, when the plus operator is used with a number and a string, the number gets converted to a string and then string concatenation is performed. So the result of this is the same as if you did num1 + num2 as the value is "109".

Example #4

var message = "Hello world!";

Just a simple string variable, nothing fancy here.

  • What is the value of message.substring(1, 4)? The first argument is the index of the first character you want and the second argument is the index of the character after the last one you want. In this case, you want the second character (index 1) through the fourth character (index 3). So the result is “ell”.
  • What is the value of message.substr(1,4)? The first argument is the index of the first character you want and the second argument is how many characters to retrieve. In this case, you want the second character (index 1) and then three more characters, so the result is “ello”.

Example #5

var o = {
        x: 8,

        valueOf: function(){
            return this.x + 2;
        },
        toString: function(){
            return this.x.toString();
        }
    },
    result = o < "9";

alert(o);

This is perhaps the most difficult of the code examples because you need to understand how valueOf() and toString() work. All objects have these two methods as they are defined on Object.prototype and inherited through the prototype chain (nitpickers will note that it’s possible to have objects that don’t inherit from Object, but I’m trying to keep this simple). These two methods get called behind-the-scenes all the time. The valueOf() method is called whenever comparisons are done and toString() is called whenever automatic conversion into a string is necessary. By overriding these methods, you can control the values they return in various circumstances.

  • What is the value result? The valueOf() method gets called behind-the-scenes here, so really the comparison is 10 < “9″. As you learned earlier, a comparison between a number and a string causes the string to be converted into a number, so the comparison ends up being 10 < 9, which is false.
  • What is the value displayed in the alert? Values passed into alert() are converted to strings, which means that toString() gets called. The alert, therefore, displays "8".

That’s it!

I hope you’ve enjoyed this little JavaScript quiz and hopefully learned a thing or two.

Update (18-Feb-2010): Fixed typo in answer #1.

Related posts

P.S. My new book, High Performance JavaScript is coming out in early 2010. Need help now? Check out Professional JavaScript, 2nd Edition.

]]> http://www.nczonline.net/blog/2010/02/18/my-javascript-quiz-answers/feed/ http://www.nczonline.net/blog/2010/02/18/my-javascript-quiz-answers/ My JavaScript quiz http://feedproxy.google.com/~r/nczonline/~3/LLqnEt2TPOU/ http://www.nczonline.net/blog/2010/02/16/my-javascript-quiz/#comments Tue, 16 Feb 2010 13:00:29 +0000 Nicholas C. Zakas http://www.nczonline.net/blog/?p=2399 Recently, there have been a couple of JavaScript quizzes floating around. There was one by Dmitry Baranovskiy (for which I explained the answers) and one by Kangax. But there are so many strange pieces of JavaScript that I thought I’d put together a quiz of my own. I’ve decided that each part will be a single code example followed by one or more questions. Once again, I don’t think such quizzes are useful for job interviews, but they are fun to test the depths of your knowledge. Without further adieu, here it is (answers to follow by end of week).

Example #1

var num1 = 5,
    num2 = 10,
    result = num1+++num2;

Questions:

  • What is the value of result?
  • What is the value of num1?
  • What is the value of num2?

Example #2

var x = 5,
    o = {
        x: 10,
        doIt: function doIt(){
            var x = 20;
            setTimeout(function(){
                alert(this.x);
            }, 10);
        }
    };
o.doIt();

Questions:

  • What value is displayed in the alert?

Example #3

var num1 = "10",
    num2 = "9";

Questions:

  • What is the value of num1 < num2?
  • What is the value of +num1 < num2?
  • What is the value of num1 + num2?
  • What is the value of +num1 + num2?

Example #4

var message = "Hello world!";

Questions:

  • What is the value of message.substring(1, 4)?
  • What is the value of message.substr(1,4)?

Example #5

var o = {
        x: 8,

        valueOf: function(){
            return this.x + 2;
        },
        toString: function(){
            return this.x.toString();
        }
    },
    result = o < "9";

alert(o);

Questions:

  • What is the value result?
  • What is the value displayed in the alert?

That’s it!

Whereas the other quizzes might have made your eyes cross trying to trace scope changes and the like, I wanted this one to be as dead simple as possible. The point? JavaScript is complex enough when written simply. Try to answer the questions without running the code. Answers with complete explanations will follow soon.

Related posts

P.S. My new book, High Performance JavaScript is coming out in early 2010. Need help now? Check out Professional JavaScript, 2nd Edition.

]]> http://www.nczonline.net/blog/2010/02/16/my-javascript-quiz/feed/ http://www.nczonline.net/blog/2010/02/16/my-javascript-quiz/ Announcing High Performance JavaScript http://feedproxy.google.com/~r/nczonline/~3/G9xaketnsds/ http://www.nczonline.net/blog/2010/02/09/announcing-high-performance-javascript/#comments Tue, 09 Feb 2010 13:00:51 +0000 Nicholas C. Zakas http://www.nczonline.net/blog/?p=2394 High Performance JavaScript Book CoverLast year was one in which I did a lot of research on performance, resulting in the Speed Up Your JavaScript blog post series (part 1, part 2, part 3, part 4) as well as several talks, namely JavaScript Variable Performance at the San Francisco JavaScript Meetup, Speed Up Your JavaScript at Google (video), and Writing Efficient JavaScript at Velocity. I was then asked my Steve Souders to contribute a chapter on JavaScript performance to his book, Even Faster Web Sites. While writing that chapter, I felt like I had far too little space to explore so wide of a topic.

Not long after that, I was approached by Havi Hoffman of the Yahoo! Developer Network to see if I would be interested in writing a book on JavaScript performance to be published by Yahoo! Press. You may be familiar with the first Yahoo! Press book, JavaScript: The Good Parts by Douglas Crockford, but there’s also Hadoop: The Definitive Guide (Tom White) and Designing Social Interfaces (Christian Crumlish & Erin Malone). Each features invaluable knowledge from some of Yahoo!’s best and brightest. I have to admit that it was a dream of mine to write for Yahoo! since I first joined the company, and this was the perfect opportunity.

In March, High Performance JavaScript will officially hit the shelves (it’s available for pre-order now on Amazon). My vision for this book was to expand upon the chapter I wrote in Even Faster Web Sites and wanted very much to keep the overall statistics-driven approach that Steve had employed. But in order to make this book the absolute best that it could be, I also borrowed Steve’s idea and sought out some of the smartest engineers I know to contribute to the book. So this book features chapters written by the following:

  • Ross Harmes, co-author of Pro JavaScript Design Patterns and front-end engineer for Flickr. Ross writes about Ajax performance with an eye on squeezing out the fastest client-server messaging possible.
  • Julien Lecomte, creator of the YUI Compressor and front-end engineer on Yahoo! Search. Julien describes effectively deploying your JavaScript with performance in mind.
  • Steven Levithan, co-author of the Regular Expression Cookbook and guru on all things related to strings and regular expressions. Steven explains the ins and outs of string and regular expression performance in JavaScript in a way that I believe has never been done before. He’s also running a contest to win a free copy of the book.
  • Matt Sweeney, YUI 3 architect. Matt focuses on currently available tools for measuring JavaScript performance.
  • Stoyan Stefanov, author of Object-Oriented JavaScript and front-end engineer on Yahoo! Search. Stoyan investigates the performance of the DOM and how reflows and repaints affect JavaScript’s perceived performance. This chapter, to me, will be the definitive print resource for reflow information.

Of course, there’s also five chapters written by me, making this a ten-chapter intensive look at JavaScript performance in the browser. I tried to make sure we covered all angles of the JavaScript lifecycle, from getting the code onto the page, executing the code, and deploying into production. I’m very, very excited about this book and the positive impact it can have on JavaScript developers. Don’t be fooled by faster JavaScript engines, JavaScript performance is going to continue to be important to understand for years to come. I hope you enjoy the book!

Related posts

P.S. My new book, High Performance JavaScript is coming out in early 2010. Need help now? Check out Professional JavaScript, 2nd Edition.

]]> http://www.nczonline.net/blog/2010/02/09/announcing-high-performance-javascript/feed/ http://www.nczonline.net/blog/2010/02/09/announcing-high-performance-javascript/ How Internet Explorer 8 document mode affects JavaScript http://feedproxy.google.com/~r/nczonline/~3/Tn7FT-QLK1s/ http://www.nczonline.net/blog/2010/02/02/how-internet-explorer-8-document-mode-affects-javascript/#comments Tue, 02 Feb 2010 13:00:30 +0000 Nicholas C. Zakas http://www.nczonline.net/blog/?p=2392 In a previous post, I talked about Internet Explorer 8’s wide array of browser and document modes. Most people are pretty familiar with how the various document modes affect layout in terms of how CSS is implemented, but what has been lost is how the document mode affects the core JavaScript engine in the browser. These changes are somewhat subtle, but important to understand when you’re working with Internet Explorer 8.

A couple of years ago, Microsoft published a paper called, JScript Deviations from ES3, in which they outlined ways in which the JScript engine (the one power Internet Explorer’s JavaScript) had deviated from the ECMAScript 3 standard. These deviations are somewhat innocuous, but chances are that you’ve been bitten by one or more of them at some point in the past. In Microsoft’s attempt to make Internet Explorer 8 more standards-compliant, the same issues that arose around CSS also arose around JavaScript. They could fix the deviations in JScript, but if the browser were running in IE5 or IE7 document modes, there could be problems as these fixes might be incompatible with the code targeting those browsers.

Microsoft chose to create versioned features of the JScript engine for Internet Explorer 8. For IE5 and IE7 document modes, the JScript engine acts as it did in the actual Internet Explorer 7, complete with all deviations from ECMAScript 3. When in IE8 document mode, the deviations are gone and you get the full power of the JScript engine.

Native JSON

Internet Explorer 8’s JScript engine implements the native JSON object object as defined by ECMAScript 5. The object is only present, however, when the page is running in IE8 document mode. This includes the global JSON object as well as methods used for JSON functionality:

  • Date.prototype.toJSON()
  • Number.prototype.toJSON()
  • String.prototype.toJSON()
  • Boolean.prototype.toJSON()

The JSON object and these methods in IE5 or IE7 document mode are undefined.

Note: Even though Date.prototype.toJSON() is supported in IE8 document, Date.prototype.toISOString() is not implemented. This is strange because they return the same value.

DOM getters/setters

One of the more curious aspects of the JScript engine is that it implements ECMAScript 5 getters and setters, but only for DOM objects and not for native JavaScript objects. The implementation is made up of half-baked versions of Object.defineProperty() and Object.getOwnPropertyDescriptor() that primarily support the get and set properties. For example:

Object.defineProperty(document.body, "active", {
    set: function(value){
        document.body.className = (value !== false) ? "active" : "";
    },

    get: function(){
        return document.body.className == "active";
    }

});

var descriptor = Object.getOwnPropertyDescriptor(document.body, "innerHTML");
alert(descriptor.get);   //displays function

Both methods are only available in IE8 document mode and do not exist in other document modes.

Arrays

One of the areas where the JScript implementation really fell apart was in dealing with arrays. Arrays had the most deviations from the ECMAScript 3 standard and were a constant source of headaches for developers. First, if undefined is passed into join(), the argument was translated into the string “undefined” and that was used to concatenate the items. For example:

var colors = ["red", "green", "blue"];
alert(colors.join(undefined));    //"redundefinedgreenundefinedblue" in IE7

When running in IE8 document mode, a value of undefined is ignored and the default separator (a comma) is used.

The unshift() method, which pushes an item to the front of the array, also had a deviation in JScript. Instead of returning the length of the array after adding the item, it simply returned undefined. In IE8 document mode, this has been fixed so that unshift() correctly returns the array length.

The last big change to arrays is the ability to properly inherit from the Array type. Dean Edwards has a whole post about trying to create a subtype of Array and the problems he encountered. The biggest problem is that assigning an instance of Array to be another constructor’s prototype meant that the length property would no longer work. Consider the following:

function MyArray(){
}

MyArray.prototype = new Array();
MyArray.prototype.get = function(i){
    return this[i];
};

var colors = new MyArray();
colors.push("red");
colors.push("green");
colors.sort();
alert(colors.get(0));    //"green"
alert(colors.length);    //in IE7, outputs "0"; in IE8, outputs "2"

In Internet Explorer prior to 8, the length property of any Array type descendant didn’t change automatically, and so inheritance was only truly useful only for non-IE browsers. In IE8 document mode, though, the length property works as it does in other browsers while IE5 and IE7 document modes use the old deviated behavior.

Miscellaneous fixes

There’s a small group of fixes that can’t really be logically categorized but nonetheless help JScript come more into agreement with other JavaScript implementations. The first is that object literals now allow trailing commas. Prior to Internet Explorer 8, the following would cause a parse error:

var object = {
    name: "value",
};

The trailing comma after the last property value is explicitly allowed by ECMAScript 3 syntax and is allowed in all other browsers. IE8 document mode now also supports this syntax correctly (other document modes still throw the error).

Another nice enhancement is that IE8 document mode now allows access to characters in a string via bracket notation:

var s = "Hello world!";
alert(s[0]);    //"H"

This brings JScript into line with other JavaScript engines; IE5 and IE7 document modes will still return undefined.

Two other changes that likely don’t affect you but are worth noting:

  • Number.prototype.toPrecision() used to throw an error when undefined was passed in. IE8 document mode now defaults to calling Number.prototype.toString() in this case.
  • Error.prototype.toString() has been properly implemented to provide better error messages.

Conclusion

IE8 document mode offers a whole host of improvements over Internet Explorer 7 not just in CSS but also in JavaScript. If you’re looking to write the most standards-compliant code possible, make sure your page is being run on Internet Explorer 8 in IE8 document mode (see my previous post for details). Bringing JScript into line with other JavaScript engines is an incredibly important step. It’s too bad that these details were pretty much overlooked in the Internet Explorer 8 announcements.

Related posts

P.S. My new book, High Performance JavaScript is coming out in early 2010. Need help now? Check out Professional JavaScript, 2nd Edition.

]]> http://www.nczonline.net/blog/2010/02/02/how-internet-explorer-8-document-mode-affects-javascript/feed/ http://www.nczonline.net/blog/2010/02/02/how-internet-explorer-8-document-mode-affects-javascript/ Answering Baranovskiy’s JavaScript quiz http://feedproxy.google.com/~r/nczonline/~3/Rwif9skct9k/ http://www.nczonline.net/blog/2010/01/26/answering-baranovskiys-javascript-quiz/#comments Tue, 26 Jan 2010 13:00:24 +0000 Nicholas C. Zakas http://www.nczonline.net/blog/?p=2385 Last week, I tweeted about a JavaScript quiz I came across on Dmitry Baranovskiy’s blog entitled, So you think you know JavaScript? As with other quizzes of this type, there is only one question to answer for five different pieces of example code: what is the result? The example code tests some of the quirkier attributes of JavaScript engine behavior. I’ve seen similar quizzes in the past, sometimes by people saying that they use it as a test during job interviews. I think doing so is both disrespectful to the candidate as well as generally useless. You don’t encounter this type of quirk every day, so making that the minimum to get a job is about as useful as asking flight attendant candidate to explain jet propulsion.

Still, I liked some of the example code in this post because it can be used to explain some interesting things about JavaScript as a language. The following is an in-depth explanation of what is happening in each of those examples.

Example #1

if (!("a" in window)) {
    var a = 1;
}
alert(a);

This strange looking piece of code seems to say, “if window doesn’t have a property ‘a’, define a variable ‘a’ and assign it the value of 1.” You would then expect the alert to display the number 1. In reality, the alert displays “undefined”. To understand why this happens, you need to know three things about JavaScript.

First, all global variables are properties of window. Writing var a = 1 is functionally equivalent to writing window.a = 1. You can check to see if a global variable is declared, therefore, by using the following:

"variable-name" in window

Second, all variable declarations are hoisted to the top of the containing scope. Consider this simpler example:

alert("a" in window);
var a;

The alert in this case outputs “true” even though the variable declaration comes after the test. This is because the JavaScript engine first scans for variable declarations and moves them to the top. The engine ends up executing the code like this:

var a;
alert("a" in window);

Reading this code, it makes far more sense as to why the alert would display “true”.

The third thing you need to understand to make sense of this example is that while variable declarations are hoisted, variable initializations are not. This line is both a declaration and an initialization:

var a = 1;

You can separate out the declaration and the initialization like this:

var a;    //declaration
a = 1;    //initialization

When the JavaScript engines comes across a combination of declaration and initialization, it does this split automatically so that the declaration can be hoisted. Why isn’t the initialization hoisted? Because that could affect the value of the variable during code execution and lead to unexpected results.

So, knowing these three aspects of JavaScript, re-examine the original code. The code actually gets executed as if it were the following:

var a;
if (!("a" in window)) {
    a = 1;
}
alert(a);

Looking at this code should make the solution obvious. The variable a is declared first, and then the if statement says, “if a isn’t declared, then initialize a to have a value of 1.” Of course, this condition can never be true and so the variable a remains with its default value, undefined.

Example #2

var a = 1,
    b = function a(x) {
        x && a(--x);
    };
alert(a);

This code looks far more complex than it actually is. The result is that the alert displays the number 1, the value to which a was initialized. But why is that? Once again, this example relies on knowledge of three key aspects of JavaScript.

The first concept is that of variable declaration hoisting, which example #1 also relied upon. The second concept is that of function declaration hoisting. All function declarations are hoisted to the top of the containing scope along with variable declarations. Just to be clear, a function declaration looks like this:

function functionName(arg1, arg2){
    //function body
}

This is opposed to a function expression, which is a variable assignment:

var functionName = function(arg1, arg2){
    //function body
};

To be clear, function expressions are not hoisted. This should make sense to you now, as just with variable initialization, moving the assignment of a value from one spot in code to another can alter the execution significantly.

The third concept that you must know to both understand and get confused by this example is that function declarations override variable declarations but not variable initializations. To understand this, consider the following

function value(){
    return 1;
}
var value;
alert(typeof value);    //"function"

The variable value ends up as a function even though the variable declaration appears after the function declaration. The function declaration is given priority in this situation. However, throw in variable initialization and you get a different result:

function value(){
    return 1;
}
var value = 1;
alert(typeof value);    //"number"

Now the variable value is set to 1. The variable initialization overrides the function declaration.

Back to the example code, the function is actually a function expression despite the name. Named function expressions are not considered function declarations and therefore don’t get overridden by variable declarations. However, you’ll note that the variable containing the function expression is b while the function expression’s name is a. Browsers handle that a differently. Internet Explorer treats it as a function declaration, so it gets overridden by the variable initialization, meaning that the call to a(--x) causes an error. All other browsers allow the call to a(--x) inside of the function while a is still a number outside of the function. Basically, calling b(2) in Internet Explorer throws a JavaScript error but returns undefined in others.

All of that being said, a more correct and easier to understand version of the code would be:

var a = 1,
    b = function(x) {
        x && b(--x);
    };
alert(a);

Looking at this code, it should be clear that a will always be 1.

Example #3

function a(x) {
    return x * 2;
}
var a;
alert(a);

If you were able to understand the previous example, then this one should be pretty simple. The only thing you need to understand is that function declarations trump variable declarations unless there’s an initialization. There’s no initialization here, so the alert displays the source code of the function.

Example #4

function b(x, y, a) {
    arguments[2] = 10;
    alert(a);
}
b(1, 2, 3);

This code is a bit easier to understand as the only real question you must answer is whether the alert displays 3 or 10. The answer is 10 in all browsers. There’s only one concept you need to know to figure out this code. ECMA-262, 3rd Edition, section 10.1.8 says about an arguments object:

For each non-negative integer, arg, less than the value of the length property, a property is created with name ToString(arg) and property attributes { DontEnum }. The initial value of this property is the value of the corresponding actual parameter supplied by the caller. The first actual parameter value corresponds to arg = 0, the second to arg = 1, and so on. In the case when arg is less than the number of formal parameters for the Function object, this property shares its value with the corresponding property of the activation object. This means that changing this property changes the corresponding property of the activation object and vice versa.

In short, each entry in the arguments object is a duplicate of each named argument. Note that the values are shared, but not the memory space. The two memory spaces are kept synchronized by the JavaScript engine, which means that both arguments[2] and a contain the same value at all times. That value ends up being 10.

Example #5

function a() {
    alert(this);
}
a.call(null);

I actually considered this to be the easiest of the five examples in this quiz. It relies on understanding two JavaScript concepts.

First, you must understand how the value of the this object is determined. When a method is called on an object, this points to the object on which the method resides. Example:

var object = {
    method: function() {
        alert(this === object);    //true
    }
}
object.method();

In this code, this ends up pointing to object when object.method() is called. In the global scope, this is equivalent to window (in browsers, in non-browser environments it’s the global object equivalent), so this is also equal to window inside of a function that isn’t an object property. Example:

function method() {
    alert(this === window);    //true
}
method();

Here, this ends up pointing to the global object, window.

Armed with this knowledge, you can now tackle the second important concept: what call() does. The call() method executes a function as if it were a method of another object. The first argument becomes this inside the method, and each subsequent argument is passed as an argument to the function. Consider the following:

function method() {
    alert(this === window);
}
method();    //true
method.call(document);   //false

Here, the method() function is called such that this will be document. Therefore, the alert displays “false”.

An interesting part of ECMA-262, 3rd edition describes what should happen when null is passed in as the first argument to call():

If thisArg is null or undefined, the called function is passed the global object as the this value. Otherwise, the called function is passed ToObject(thisArg) as the this value.

So whenever null is passed to call() (or its sibling, apply()), it defaults to the global object, which is window. Given that, the example code can be rewritten in a more understandable way as:

function a() {
    alert(this);
}
a.call(window);

This code makes it obvious that the alert will be displaying the string equivalent of the window object.

Conclusion

Dmitry put together an interesting quiz from which you can actually learn some of the strange quirks of JavaScript. I hope that this writeup has helped everyone understand the details necessary to figure out what each piece of code is doing, and more importantly, why it’s doing so. Again, I caution against using these sort of quizzes for job interviews as I don’t think they serve any practical use in that realm (if you’d like to know my take on interviewing front-end engineers, see my previous post).

Related posts

P.S. My new book, High Performance JavaScript is coming out in early 2010. Need help now? Check out Professional JavaScript, 2nd Edition.

]]> http://www.nczonline.net/blog/2010/01/26/answering-baranovskiys-javascript-quiz/feed/ http://www.nczonline.net/blog/2010/01/26/answering-baranovskiys-javascript-quiz/ Internet Explorer 8 document and browser modes http://feedproxy.google.com/~r/nczonline/~3/NJSfRUtdbi4/ http://www.nczonline.net/blog/2010/01/19/internet-explorer-8-document-and-browser-modes/#comments Tue, 19 Jan 2010 13:00:06 +0000 Nicholas C. Zakas http://www.nczonline.net/blog/?p=2377 When Microsoft began planning for Internet Explorer 8, they were struck with an interesting problem. They were willing to admit that Internet Explorer had implementation bugs both in rendering and scripting. After admitting that, though, they had the problem that is commonly referred to as “don’t break the Internet.” Microsoft had no way of knowing how many sites were reliant upon the implementation bugs to function correctly. Their ultimate solution to the problem was interesting: Internet Explorer 8 could run in a variety of different modes. The sheer number of possible modes is a bit daunting but basically comes down to two types: document mode and browser mode.

Document mode

A page’s document mode determines to which features it has access. This means that there’s a specific level of CSS support, a specific number of features available for scripting through JavaScript, and a specific way that doctypes are treated. There are three different document modes:

  • Internet Explorer 5 - renders the page in IE7 quirks mode (also known as IE5 mode). New features in IE8 are not available.
  • Internet Explorer 7 - renders the page in IE7 standards mode. New features in IE8 are not available.
  • Internet Explorer 8 - renders the page in IE8 standards mode. New features in IE8 are available, so you can access the Selectors API, more CSS 2 selectors, some CSS 3 features, HTML 5 features, etc. Essentially, you get everything that IE8 has to offer.

The concept of document mode is very important for understanding how Internet Explorer 8 works.

Forcing a document mode

You can force a particular document mode by using the X-UA-Compatible HTTP header or by using the <meta> tag equivalent:

<meta http-equiv="X-UA-Compatible" content="IE=IEVersion">

There are several different possible values for the IE version in this field and they don’t necessary map to the three document modes:

  • Edge - always put the document into the most recent document mode available. Doctype is ignored. For Internet Explorer 8, this forces the document mode to IE8 standards all the time. Be careful when using this because when Internet Explorer 9 comes out, this will force the page into IE9 standards mode.
  • EmulateIE8 - if a doctype is present, set the document mode to IE8 standards and otherwise set the document mode to IE5.
  • EmulateIE7 - if a doctype is present, set the document mode to IE7 standards and otherwise set the document mode to IE5.
  • 8 - force document mode to be IE8 standards. Doctype is ignored.
  • 7 - force document mode to be IE7 standards. Doctype is ignored.
  • 5 - force document mode to be IE5. Doctype is ignored.

For example, to make the document mode behave as it would in Internet Explorer 7, you can use the following:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">

Whereas to force IE7 standards mode regardless of doctype, use this:

<meta http-equiv="X-UA-Compatible" content="IE=7">

You are not required to have an X-UA-Compatible field set on pages. If not present, the default is EmulateIE8.

Detecting document mode

You can determine the document mode for a given page using the document.documentMode property a new feature in Internet Explorer 8, which returns either 5, 7, or 8:

var mode = document.documentMode;

Using this property can give you a hint as to how the page is going to behave. This property is available in all document modes.

Browser mode

There are three browser modes: Internet Explorer 8, Internet Explorer 8 compatibility, and Internet Explorer 7. These modes affect the page in a number of ways, most notably by altering document mode and the user-agent string. By default, the browser mode is set to Internet Explorer 8.

Internet Explorer 8 mode

By default, the browser runs in Internet Explorer 8 mode. The document mode is determined as if X-UA-Compatible is set to EmulateIE8. The user-agent string for the browser includes both the Internet Explorer version and the Trident (rendering engine) version. For instance, I see this on my machine:

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Most pages end up running in Internet Explorer 8 browser mode.

Internet Explorer 8 compatibility mode

When an end user clicks the compatibility view button next to refresh button, the browser mode changes to Internet Explorer 8 compatibility. IE8 compatibility mode is meant to emulate Internet Explorer 7 and so the  document mode is determined as if X-UA-Compatible is set to EmulateIE7. The user-agent string for the browser changes the Internet Explorer version 7 but leaves Trident (rendering engine) version. For instance, I see this on my machine:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

The user-agent string change is to ensure that any code reliant on user-agent sniffing continues to function as if running in Internet Explorer 7. Leaving the Trident version allows developers the opportunity to determine that this is, in fact, Internet Explorer 8 running in compatibility mode.

Internet Explorer 7 mode

Internet Explorer 7 mode is the most curious of all browser modes as it appears to be an option in IE Developer Tools only. The documentation states that this is used to test your site in an actual Internet Explorer 7 instance rather than Internet Explorer 8 running in compatibility mode. Internet Explorer 7 determines the document mode as if X-UA-Compatible is set to EmulateIE7. Additionally, this mode completely disregards X-UA-Compatible and so there is no way to manually change the document mode (Internet Explorer 7 didn’t honor X-UA-Compatible either). This means that unlike the other browser modes, Internet Explorer 7 mode can never have a document mode of IE8 standards. Further, the user-agent string is changes so that the Trident version is no longer available. Here it is on my box:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

There doesn’t appear to be any other way that and end user can trigger Internet Explorer 7 mode. As such, it appears that this is just a convenience tool for developers that frees us from needing to  and so it appears to be a tool used primary for developers

Summary

Internet Explorer 8 has some powerful, and confusing, features as it relates to its rendering and execution engine. Document modes are used to determine which features are available to the page, and that includes which CSS features and which JavaScript features are enabled and available. You can tell the browser how you would like the document mode to be determined by specifying a value of X-UA-Compatible.

Browser modes change how the document mode is determined when X-UA-Compatible is not specified. They also change the user-agent string so that user-agent sniffers won’t be broken. In the wild, you will only see Internet Explorer 8 mode and Internet Explorer 8 compatibility mode; Internet Explorer 7 mode appears to be just for developer usage.

Related posts

P.S. My new book, High Performance JavaScript is coming out in early 2010. Need help now? Check out Professional JavaScript, 2nd Edition.

]]> http://www.nczonline.net/blog/2010/01/19/internet-explorer-8-document-and-browser-modes/feed/ http://www.nczonline.net/blog/2010/01/19/internet-explorer-8-document-and-browser-modes/