Servage Magazine

Information about YOUR hosting company – where we give you a clear picture of what we think and do!

Live-extensions for better DOM – Part 1

Wednesday, April 2nd, 2014 by Servage

Event handling is one of the key principles of working with the DOM. Events are the primary means of receiving feedback from user interaction.


In this first example, documentation and tutorials that cover DOM events is what I call “simple event binding”. You attach a listener for the desired event on the DOM element in which you expect it to happen on.

link.addEventListener("click", function(e) {
  // do something when the link is clicked
}, false);

The first argument indicates the type of an event, the second argument is a listener, and the third argument defines an event phase (so-called “bubbling” or “capturing”). The reason why the last argument exists is because most DOM events traverse the DOM tree from document node to target node (capture phase) and back to the document node (bubble phase). This process is called “event flow” and brings several powerful features.


Instead of attaching a handler for each element in a group, we can attach one listener onto an ancestor shared by all of the elements in that specific group. Then, we can determine where an event took place using the target property of the event object, passed into the listener. This is known as “event delegation”:

list.addEventListener("click", function(e) {
  if ( === "LI") {
    // do something when a child <li> element is clicked

}, false);

By having all event handlers on a particular parent, we can update the innerHTML property of this element without losing the ability to listen to events for new elements. The feature was called “Live Events” in jQuery, and it quickly became popular because of its ability to filter events by a CSS selector. Later, delegated events replaced them due to their flexibility by allowing to bind a listener to any element within the document tree.

But even event delegation does not overcome the following problems:

When DOM mutation is required after a new element (that matches a specific selector) comes into the document tree,

When an element should be initialized on a excessive event such as scroll or mousemove,

Or on non-bubbling events, e.g. load, error, etc.

This is what live Extensions aim to solve.

Live Extensions API

While designing APIs for live extensions, I decided to follow the following rules:

Live extensions should be declared in JavaScript.

I strongly believe that everything that somehow changes the behavior of an element should be presented in a JavaScript file. (Note that better-dom inserts a new CSS rule behind the scenes, but this includes only implementation details).

APIs should be simple to use.

No tricky file formats or new HTML elements: only a small amount of knowledge related to the constructor and event handlers is required to start developing a live extension (thus, the barrier to entry should be low).

As a result, there are only two methods to deal with: DOM.extend and DOM.mock.


Live-extensions for better DOM - Part 1, 5.0 out of 5 based on 1 rating
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet (leave a comment)

You are welcome to initiate a conversation about this blog entry.

Leave a comment

You must be logged in to post a comment.