Mastering Ajax, Part 4: Web Response with Dom

To convert HTML to an object model

Introduction: The watershed between programmers (using back-end applications) and WEB programmers (writing HTML, CSS, and JavaScript) is a long-standing one. However, the Document Object Model (DOM) compensates for this rift, making it practical and efficient to use XML at the back end while using HML at the front end. In this article, Brett McLaughlin introduces the Document Object Model, explains its application in Web pages, and starts digging into its use in JavaScript.

Like many WEB programmers, you may have used HTML. HTML is the way programmers begin to deal with WEB pages; HTML is usually the last step before they complete an application or site--adjust some layouts, colors, or styles. However, although HTML is often used, there is widespread misunderstanding about what happens when HTML is transferred to the browser to render on the screen. Before I analyze what you think might happen and why it might be wrong, I want you to be clear about the processes involved in designing and servicing Web pages:

1. Some people (usually you!) Create HTML in a text editor or IDE.

2. Then you upload HTML to the WEB server, such as Apache HTTPD, and expose it to the Internet or intranet.

3. The user requests your Web page with Firefox or Safaria browser.

4. The user's browser requests HTML from your server.

5. The page that the browser receives from the server is rendered graphically and in text, and the user sees and activates the Web page.

This looks very basic, but things will get interesting soon. In fact, the huge number of "fillers" (stuff) that occur between steps 4 and 5 is the focus of this article. The term "filler" is also very useful because most programmers never really consider what happens to the tag when the user's browser requests a display tag.

Does the browser simply read the text in HTML and display it?

What about CSS? Especially when the CSS is in an external file.

What about JavaScript? It is also typically located in an external file.

How do browsers handle these items, if you map event handlers, functions, and styles to that text tag?

The answer to all these questions, it turns out, is document Object Model. So talk less and study DOM directly.

Web Programmers and tags

For most programmers, their work ends when the Web browser starts. That is, when you put an HTML file in a Web browser's directory, you usually think it's "done", and (hopefully) don't think about it any more! When it comes to writing clean, well-organized pages, this is also a great goal; I want your markup to display what it should display across browsers, with various versions of CSS and JavaScript, without a single error.

The problem is that this approach limits the programmer's understanding of what really happens in the browser. More importantly, it limits your ability to dynamically update, change, and refactor Web pages with client JavaScript. Get rid of this limitation and make your Web site more interactive and creative.