The origins of JavaScript

JavaScript was developed by Netscape, in collaboration with Sun Microsystems. Before JavaScript, web browsers were fairly basic pieces of software capable of displaying hypertext documents. JavaScript was later introduced to add some extra spice to web pages and to make them more interactive. The first version, JavaScript 1.0, debuted in Netscape Navigator 2 in 1995. At the time of JavaScript 1.0’s release, Netscape Navigator dominated the browser market. Microsoft was struggling to catch up with its own browser, Internet Explorer, and was quick to follow Netscape’s lead by releasing its own VBScript language, along with a version of JavaScript called JScript, with the delivery of Internet Explorer 3. As a response to this, Netscape and Sun set about standardizing the language, together with the European Computer Manufacturers Association (ECMA).

The result was ECMAScript, yet another name for the same language. Though the name never really stuck, we should really be referring to JavaScript as ECMAScript. JavaScript, ECMAScript, JScript—whatever you want to call it—was gaining ground by 1996. Version 3 browsers from Netscape and Microsoft both supported the JavaScript 1.1 language to varying degrees. I should point out that JavaScript has nothing to do with Java, a programming language developed by Sun Microsystems. JavaScript was originally going to be called LiveScript. “JavaScript” was probably chosen to make the new language sound like it was in good company. Unfortunately, the choice of this name really only had the effect of confusing the two languages in people’s minds—a confusion that was amplified by the fact that web browsers also supported a form of client-side Java. However, while Java’s strength lies in the fact that it can theoretically be deployed in almost any environment, JavaScript was always intended for the confines of the web browser. JavaScript is a scripting language.

This means that unlike a program that does everything itself, the JavaScript language simply tells the web browser what to do. The web browser interprets the script and does all the work, which is why JavaScript is often compared unfavorably with compiled programming languages like Java and C++. But JavaScript’s relative simplicity is also its strength. Because it has a low barrier to entry, non-programmers who wanted to cut and paste scripts into their existing web pages quickly adopted the language. JavaScript also offered developers the chance to manipulate aspects of the web browser. For example, the language could be used to manipulate the properties of a browser window, such as its height, width, and position. Addressing the browser’s own properties in this way can be thought of as a Browser Object Model (BOM). Early versions of JavaScript also provided a primitive sort of Document Object Model.

What is a Document Object Model?

In short, a Document Object Model (DOM) is a way of conceptualizing the contents of a document. In the real world, we all share something I’ll call a World Object Model. We can refer to objects in our environment using terms like “car,” “house,” and “tree” and be fairly certain that our terms will be understood. That’s because we have mutually agreed upon which objects the words refer to specifically. If I say “The car is in the garage,” it’s safe to assume that you won’t take that to mean “The bird is in the cupboard.” Our World Object Model isn’t restricted to tangible objects though—it also applies to concepts.

For instance, I might refer to “the third house on the left,” when giving you directions. For that description to make sense, the concepts of “third” and “left” must be understood. If I give that description to somebody who can’t count, or who can’t tell left from right, then the description is essentially meaningless, whether or not the words have been understood. In reality, because people agree on a conceptual world model, very brief descriptions can be full of meaning. I can be fairly sure that others share my concepts of “left” and “third.” It’s the same situation with web pages. Early versions of JavaScript offered developers the ability to query and manipulate some of the actual contents of web documents—mostly images and forms. Because the terms “images” and “forms” had been predefined, JavaScript could be used to address “the third image in the document” or “the form named ‘details,’” as shown:

 

document.images[2] document.forms['details']

This first, tentative sort of Document Object Model is often referred to as DOM Level 0. In those early, carefree days, the most common usage of DOM Level 0 was for image rollovers and some client-side form validation. But when the fourth generation of browsers from Netscape and Microsoft appeared, the DOM really hit the fan.

The browser wars

Netscape Navigator 4 (NN4) was released in June 1997, and by October of that year, Internet Explorer 4 (IE4) had also been released. Both browsers promised many improvements on previous versions, along with many additions to what could be accomplished with JavaScript, using a greatly expanded DOM. Web designers were encouraged to test-drive the latest buzzword: DHTML.

The D word: DHTML

DHTML was short for dynamic HTML. Not a technology in and of itself, DHTML was a shorthand term for describing the marriage of HTML, CSS, and JavaScript. The thinking behind DHTML went like this: You could use HTML to mark up your web page into elements. You could use CSS to style and position those elements. You could use JavaScript to manipulate and change those styles on the fly. DHTML referred to the combination of those three techniques. Using DHTML, complex animation effects suddenly became possible. Let’s say you used HTML to mark up a page element like this:

 

<div id="myelement">This is my element</div>

You could then use CSS to apply positioning styles like this:

 

#myelement { position: absolute; left: 50px; top: 100px; }

Then, using JavaScript, you could change the left and top styles of myelement to move it around the page. Well, that was the theory anyway. Unfortunately for developers, both browsers used different, incompatible DOMs. Although the browser manufacturers were promoting the same ends, they each approached the DOM issue in completely different ways.

Clash of the browsers

The Netscape DOM made use of proprietary elements called layers. These layers were given unique IDs and then addressed through JavaScript like this:

 

document.layers['myelement']

Meanwhile, the Microsoft DOM would address the same element like this:

 

document.all['myelement']

The differences didn’t end there. Let’s say you wanted to find out the left position of myelement and assign it to the variable xpos. In Netscape Navigator 4 you would do it like this:

 

var xpos = document.layers['myelement'].left;

Here’s how you would do the same thing in Internet Explorer 4:

 

var xpos = document.all['myelement'].leftpos;

This was clearly a ridiculous situation. Developers had to fork their code to accomplish any sort of DOM scripting. In effect, many scripts were written twice, once for NN4 and once for IE4. Convoluted browser sniffing was often required to serve up the correct script. DHTML promised a world of possibilities. But anybody who actually attempted to use it discovered a world of pain instead. It wasn’t long before DHTML became a dirty (buzz)word. The technology quickly garnered a reputation for being both over hyped and overly difficult to implement.

Raising the standard

While the browser manufacturers were busy engaging in their battle for supremacy, and using competing DOMs as weapons in their war, the W3C was quietly putting together a standardized Document Object Model. Fortunately, the browser vendors were able to set aside their mutual animosity. Netscape, Microsoft, and other browser manufacturers worked together with the W3C on the new standard and DOM Level 1 was completed in October 1998. Going back to our example, let’s take a look at how the new standardized DOM would tackle the same situation. Remember, we have a <div> with the ID myelement and we’re trying to ascertain the value that has been applied to its left position so that we can store that value as the variable xpos. Here’s the syntax we would use:

 

var xpos = document.getElementById('myelement').style.left

At first glance, that might not appear to be an improvement over the non-standard, proprietary DOMs. However, the standardized DOM is far more ambitious in its scope. While the browser manufacturers simply wanted some way to manipulate web pages with JavaScript, the W3C proposed a model that could be used by any programming language to manipulate any document written in any markup language.

Thinking outside the browser

The DOM is what’s known as an Application Programming Interface (API). APIs are essentially conventions that have been agreed upon by mutual consent. Real-world equivalents would be things like:

1. Morse code
2. International time zones
3. The periodic table of the elements

All of these things are standards, and they make it easier for people to communicate and cooperate. In situations where a single convention hasn’t been agreed upon, the result is often disastrous. Remember, competition between metric and imperial measurements has resulted in at least one failed Mars mission. In the world of programming, there are many different languages, but there are many similar tasks. That’s why APIs are so handy. Once you know the standard, you can apply it in many different environments. The syntax may change depending on the language you’re using, but the convention remains the same.

So, while I focus specifically on using the DOM with JavaScript in this article, your new knowledge of the DOM will also be very useful if you ever need to parse an XML document using a programming language like PHP or Python. The W3C defines the DOM as “A platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure, and style of documents.” The independence of the standardized DOM, together with its powerful scope, places it head and shoulders above the proprietary DOMs created by the bickering browser manufacturers.

The end of the browser wars Microsoft won the battle for browser market-share supremacy. Ironically, the clash of competing DOMs and proprietary markup had little effect on the final outcome. Internet Explorer was destined to win simply by virtue of the fact that it came pre-installed on all PCs running the Windows operating system. The people who were hit hardest by the browser wars were web designers. Cross-browser development had become a nightmare. As well as the discrepancies in JavaScript implementations that I mentioned earlier, the two browsers also had very different levels of support for CSS. Creating style sheets and scripts that worked on both browsers became a kind of black art. A backlash began against the proprietary stance of the browser manufacturers.

A group was formed calling itself the Web Standards Project, or the WaSP for short (http://webstandards.org/). The first task that the WaSP undertook was to encourage browser makers to adopt W3C recommendations—the very same recommendations that the browser manufacturers had helped draft. Whether it was due to pressure from the WaSP or the result of internal company decisions, there was far greater support for web standards in the next generation of web browsers.

A new beginning

Internet Explorer 5 shipped with built-in support for WC3’s standardized DOM, while also maintaining support for the old, proprietary Microsoft DOM. Netscape decided to make a clean break and released a browser that had next to nothing in common with NN4. Netscape Navigator 6 even skipped a version number, and it used a completely different rendering engine with far, far greater CSS support. It also supported the standardized DOM, but without any backwards compatibility for the old Netscape DOM. Subsequent releases from both Netscape and Microsoft improved on previous incarnations with increased support for web standards. Unfortunately, development of Internet Explorer has stagnated at version 6. This is a pity, as some problems still remain with the browser’s implementation of CSS. Support for DOM Level 1, however, is rock solid. In the meantime, other browsers have appeared on the scene. When Apple debuted its Safari web browser in 2003, there was no question that it would follow the DOM standards.

Firefox, Mozilla, and Camino, all based on the same open-source rendering engine as Netscape 6 and 7, have excellent support for the DOM. Opera and Konquerer also offer great DOM support. Over 95% of the browsers in active use today have built-in support for the DOM. The browser wars of the late nineties appear to be well and truly behind us. Although no single browser has implemented the W3C DOM perfectly, all modern browsers cover about 95% of the specifications. This means there’s a huge amount that we can accomplish without having to worry about branching code. The stagnated development of Internet Explorer notwithstanding, life has improved greatly for web designers. Instead of writing scripts with forked code served up with complicated browser sniffing, we are now in a position to write something once and publish it everywhere. As long as we follow the DOM standards, we can be sure that our scripts will work almost universally.

What’s next?

One thing you should definitely take away from my brief JavaScript history lesson is that different browsers used to accomplish the same tasks in different ways. This inescapable fact dominated not just the writing of JavaScript scripts, it also dictated how articles about JavaScript were written. Any JavaScript articles aimed at demonstrating how to learn the language by example often had to show the same scripts written in different ways for different browsers. Just like the code found on most websites, the examples in most JavaScript articles were full of browser sniffing and code branching. Similarly, technical reference articles on JavaScript couldn’t simply contain lists of functions and methods. They also had to document which functions and methods were supported by which browsers. The situation has changed now.

Thanks to the standardization of the DOM, different browsers do the same things in much the same way. This means that when I’m showing you how to do something using JavaScript and the Document Object Model, we won’t get sidetracked by browser inconsistencies. I am going to try to avoid mentioning any specific browsers in this article. I’m also not going to use the term DHTML any more. The term always worked better as a marketing buzzword than as a technical description. For one thing, it sounds confusingly like another flavor of HTML or XHTML. Also, the term comes with a lot of baggage. If you mention DHTML to anyone who tried using it in the late nineties, you’ll have a hard time convincing them that it’s a straightforward, standardized technology now. DHTML was supposed to refer to the combination of (X)HTML, CSS, and JavaScript, but in actual fact, what binds these things together is the DOM. If we need any term to describe this process, let’s use something more accurate. While the term DHTML could be used to refer to browser-specific coding, it doesn’t seem right to try to apply the same term to standards-based coding.

DOM Scripting is a more accurate way to describe the manipulation of documents and style sheets using the W3C Document Object Model. Whereas DHTML referred only to web documents, DOM Scripting can be used in conjunction with any marked-up document using any language that supports the DOM API. In the case of web documents, the ubiquity of JavaScript makes it the best choice for DOM Scripting.