We have plenty of platforms to support and despite the great efforts of groups trying to set standards, differences and bugs still get pushed out into the market. Innocent consumers use these platforms to the great pain of many developers who are forced to support them until the offending platform dies. Rest in pieces IE6. However, out of all the fragmentation and differences that exists, fewer things have caused more headaches, late nights, and tears than the Document Object Model (DOM).
"The Document Object Model is an API for HTML and XML documents. It provides a structural representation of the document, enabling you to modify its content and visual presentation. Essentially, it connects web pages to scripts or programming languages." - Mozilla Developer Network
The Document Object Model is standardized by the W3C and it defines an interface to abstract HTML and XML documents as objects. The DOM provides us with a document structure, tree model, Event architecture, DocumentFragments, Elements and even more process heavy behaviors such as DOM Traversal.
Hyper Text Markup Language or HTML is the web's markup language and it is specified in terms of the DOM. The HTML DOM includes things like the className property on HTML elements or different APIs like document.body.
Remember our talks about fragmentation? Yeah, that applies here. Each browser has a subtly different implementation of the DOM. Honestly, in some cases, they aren't terribly subtle at all. In fact, nearly every DOM method is broken in some way or another in some browser. Since the DOM is what connects web pages to programming languages, our program will have to handle all the different use cases to support each browser.
This is a very commonly used DOM method to grab all elements that have a certain tag name, which is the name of an element. Given an HTML document that looks like this:
<ul> <li>Name: Merrick</li> <li id="length">Height: 6' Tall</li> </ul>
If I call this:
var els = document.getElementsByTagName('li');
I now have a collection of
<li> tags selected. Now lets count the number of elements that have been selected, we use the length property for that.
console.log(els.length); // Returns 2
Works great! Unfortunately, in Internet Explorer the length property will get overwritten because we have an element in our example above with an `id="length". :(
The querySelectorAll method finds DOM elements using CSS selectors. Unfortunately, the method doesn't even exist in quirks mode in IE 8 and id selectors don't match at all in XML documents.
These two DOM methods I've just shown also happen to be the most popular and both contain very serious problems when used in different browsers. When working with other DOM features be prepard to find other obvious inconsistencies especially with Events and AJAX requests. To solve this problem we need an abstraction layer. Something our program can talk to that mitigates these issues and handles the browser specific bugs for us.
DOM libraries are the solution to this problem. They offer a consistent API to interact with the DOM that will work cross browser. It's safe to say that this comes as a very welcomed relief! Let's revisit our examples above, by using the popular library jQuery we can select and output the length across all browsers with great ease.
console.log($('li').length); // Returns 2 everywhere!
Most DOM libraries typically include abstractions for AJAX requests, DOM selection, traversal, and manipulation (like CSS and attributes), as well as event implementations like click.
DOM Libraries are a key tool for fixing cross browser incompatibilities and bugs.
There are many, many more DOM libraries to choose from but the important thing to remember is that they are all trying to solve the same problem, by providing you with a consistent API for common web development tasks like DOM manipulation, AJAX requests, and event management that will work cross browser.
Next we will talk about the spaghetti code that can occur when you lean too heavily on a DOM library like jQuery, and a whole new set of tooling to help solve that problem. Move on to the next article, MV* Libraries and Frameworks.