There are three event handling models in javascript; the W3C, Internet Explorer's and Netscape 4's. As per browser war methodology, they are also incompatible.

The Firefox bubbling method starts with the document and propagates down the tree until the element the event occurred on is found. Any handlers attached above the element with the event will have priority. Internet Explorer does the opposite and searches for handlers by going up the tree from the event's source.

Ultimately, this means you can attach an event higher in the div hierarchy than the div you want to listen to for events. This is important when attaching events to a div which may get removed from the DOM due to dhtml requirements. Especially in Internet Explorer as divs and events are separate COM objects and removing a div can leave an event causing a memory leak.

The console.log shows that event object's output in firebug. The code itself is below. I used dojo to abstract out the event handling differences between W3C and IE7.

The event is attached to the div with id=one. Clicking on three, two or one gets caught by the event handler on id=one. In the first screenshot I clicked on the div id=three and it was registered as the target even though the event on id=one caught it. (more)
Because Javascript has functions as obvious top level objects it can be easy to move the scoping of variables around using closures. It is probably the power of the language as it makes callback code very, very simple to implement. The downside is that in a complex object literal the keyword 'this' can have three different scopings. From here:

Closures can be a nice tool for creating your own DSL, to make your code get closer to the design model. But closures can also take you further away from the design model, by creating constructs that only make sense in the abstract.

One of the purposes of Object Oriented Programming is to make scope consistent and opaque. Closures mess with this paradigm by moving the scope of variable into the domain of other objects. So that comment makes a good point. The problem is that closures are so useful and simplify numerous problems by their properties.
It can sometimes be difficult to go to a loosely typed from language from a strongly typed one. Especially with conditionals. I hit this issue today where I had it in my mind that the variable was an integer but the javascript runtime treated it as a boolean. To code phrase the issue: 

function test(v) {
    return v || 1;
}
var value = test(0);

Usually that kind of OR is a quick check if the variable being passed in is undefined or null and then set the second value as the default. In this case the 0 is a concrete number, the problem is that the javascript compiler treats it as a boolean and zero resolves to false in the conditional. This means the returned value is 1. Not much fun when you are expecting the returned value to be an integer of 0.

It is a quirk of the Javascript language that many things will resolve to false; including undefined, null, 0 and "". In most cases this can be taken advantage of, except when it can't like I ran into today.
Following on from the previous article on encapsulation with OOP Javascript. A better example is a Ticket business object that has the internal business rule of not being able to be invoiced unless there is a work complete date. 

function Ticket() {
   this.work_complete = null;
   this.invoice_date = null;  
 }
 Ticket.prototype.invoice_ticket = function() {
   if (this.work_complete != null) {
     this.invoice_date = new Date();
   } else {
     throw "Ticket cannot be invoiced unless work is complete.";
   }
 }

We can test it with: 

ticket = new Ticket();
 
 // fails business rule encapsulated in business object
 try {
   ticket.invoice_ticket();
 } catch (error) {
   alert(error);
 }
 
 // passes business rule encapsulated in business object
 ticket.work_complete = new Date();
 try {
   ticket.invoice_ticket();
   alert("Ticket is invoiced for " + ticket.invoice_date);
 } catch (error) {
   alert(error);
 }
Encapsulation is the process of hiding an object's details from external objects which seek to interact with it. This means there is a strong public interface to the object and the messy business logic of how it presents that public face is not of concern to the outside world. This strong decoupling of interface from implementation means that external objects are not dependent or susceptible to changes of the internal business logic of the object.

As an example with the CleanJot object we probably don't care if it appears as a variable or a method. For consistency's sake it is more readable as a variable. 

function Jot(v_username, v_description_html) {
   this.username = v_username;
   this.description_html = v_description_html;
 }
 function CleanJot(v_username, v_description_html) {
   Jot.call(this, v_username, v_description_html);
   this.description = this.description_html.replace('<p>','\n');  
 }
 clean = new CleanJot('cam','over<p>under');
 alert(clean.description_html);
 alert(clean.description);
In OOP inheritance is a sub-class adopting its parents protected and public attributes and methods upon instantiation. To continue to the use the Jot example, a basic Jot accepts two strings from the Controller. A username and a description_html string which contains html tags in a string format. 

function Jot(username, description_html) {
   this._username = username;
   this._description_html = description_html;
 }

Now the database stores the description in raw string format and html in case there are instances of the user not entering paragraph tags and using hard returns instead. So to edit a Jot the user may not want to see the additional formatting tags added in through using BeautifulSoup.

In which case we need a CleanJot object. 

function CleanJot(username, description_html) {
   Jot.call(this, username, description_html);
 }
 CleanJot.prototype.getDescription = function() {
     return this._description_html.replace('<p>','\n');
 }

The thing to note in the subclass is the use of call() which is an inbuilt Javascript method analogous to super() in Java. So if we instantiate CleanJot we have access to _username, _description_html and getDescription(). For example: 

 clean = new CleanJot('cam','overunder');
 alert(clean._description_html);
 alert(clean.getDescription());
Does a prototype declaration over-ride a variable of the same name being set in a javascript constructor? 

function Rock() {
  this.face = "mossy";
}
 
rock = new Rock();
alert(rock.face);
Rock.prototype.face = "dry";
alert(rock.face);
rock2 = new Rock();
alert(rock2.face);

The output is "mossy", "mossy" and "mossy". So the answer is no. (more)
Prototyping can also be used to add functionality to existing or core objects whose internal details you have no control over. This can be done without the need for subclassing the object and having to use inheritance to achieve that behavior.

Adding prototype functionality to the Date() object is a good example. A common cause of confusion between American and Australian dates is that the Month and Date are in opposite positions when dates are written in local shorthand.

For instance: 

Date.prototype.getAustralianDate = function() {
  return (this.getDate() + '/'
     + this.getMonth() + '/'
     + this.getFullYear());
 }
 Date.prototype.getAmericanDate = function() {
   return (this.getMonth() + '/'
     + this.getDate() + '/' 
     + this.getFullYear());
 }

And to test it: 

d = new Date();
alert(d.getAustralianDate() + "\n" + d.getAmericanDate());

The alert shows the Australian style of date on the first line and the American style on the second line.
Javascript is sufficient object aware that object oriented design can be done with the language. The semantics for OO Javascript are alien to most of the current popular OO languages such as Java, C# and Python.

The main difference is the lack of a class keyword in Javascript so a class declaration is done with a function instead and the methods of the object are not bounded by the brackets {} or whitespace under the class keyword. One of the good things of the C-like languages and python's white space is that it makes for an aesthetic rigor so that encapsulation is held within a physical space in the source code, not just a compiler recognised one.

Rather than having a rats nest of nested literal functions inside an object declared with a function in Javascript the prototype property enables semantic and aesthetic appearance of encapsulation.

The prototype allows attributes and methods to be attached to an object. For instance: 

 function Jot(username, description_html) {
   this._username = username;
   this._description_html = description_html;
 } 
 Jot.prototype.getDescription = function() {
     return this._description_html.replace('<p>','\n');
 }

Which exposes the object's members username and description_html and the method which returns the description without paragraph tags.
A javascript constant uses the const identifier and is a read-only definition. Like javascript variables constants have global and local scope. Using the perennial Circle example: 

const PI = 3.14159;

function Circle(radius) {
  this.radius = radius;
  this.circumference = function() {
    return this.radius * 2 * PI;
  }  
}

circle = new Circle(10);
alert(circle.circumference());

There is a Math.PI constant in the javascript libraries. So this isn't necessarily a good example. A constant can be declared and used in a javascript object as a private variable and its scope will only be in the object. 

function Circle(radius) {
  this.radius = radius;
  const PI = 3.14159;
  this.circumference = function() {
    return this.radius * 2 * PI;
  }
  this.expansion = function(by) {
    return this.radius * by * 2 * PI;
  }  
}

But what if we place a constant in global scope above a Javascript object, then try to change that constant by declaring it again in a function that is run from onload() in the body tag? 

const PI = 3;
function Circle(radius) {
  this.radius = radius;
  this.circumference = function() {
    return this.radius * 2 * PI;
  }
  this.expansion = function(by) {
    return this.radius * by * 2 * PI;
  }  
}

function run() {
circle = new Circle(10);
alert(circle.expansion(2));
const PI = 3.14159;
alert(circle.expansion(2));

I deliberately used 3 as the initial PI declaration, though I think some town passed a law once that pi was equal to three, to differentiate from the 3.142 results.

The Circle picks up the PI constant as 3 despite trying to override the constant in the run() method. If we reorganise the run method to put the redeclared constant before the instantiation of the Circle the result is the same. 

function run() {
const PI = 3.14159;
circle = new Circle(10);
alert(circle.expansion(2));
}

The global scoping of the constant over-rides the local scoping of a constant with the same name. If PI is declared in the global scope twice there is a javascript error, "redeclaration of const".
Cam Riley: South Sea Republic. Freedom, liberty, equity and an Australian Republic.