1.2. Dynamic Web Pages

Static web pages have three major problems. The first is that they're boring. Think of it as visiting the park down the road on vacation every year. Unless that park is Yellowstone, or there's lots of alcohol involved, it's going to get old very quickly.

The second problem is that, unlike a dumb terminal, a personal computer has processing power of its own. Some, in fact, have more processing power than the web servers that they are communicating with. Why not take advantage of this processing power? It won't cost the server anything to utilize this essentially free resource.

The final problem with static web pages is that all validation is performed by the server. This means that if a user enters a telephone number as (999)999-9999 instead of 999-999-9999, it is up to the server to catch the error and inform the user of the correct format. So the user is forced to endure the entire cycle in which the form is sent to the server, which finds the error and then sends the whole page back to the web browser. And unless the web developer took care to retain the information already entered, the user is forced to re-enter everything. I don't know about you, but this wouldn't give me the warm fuzzes about a website.

For all of these reasons and the "wouldn't it be cool?" factor, a technique called Dynamic Hypertext Markup Language, or DHMTL, was created. Even at first glance, it was obvious that there was a vast difference between static web pages and pages that employed DHTML techniques. The first of these differences is that things happened on dynamic web pages.

There were events. No, not events like the grand opening of the Wal-Mart Super Center down the roadbrowser events. When the mouse pointer was moved around the page, things happened, and not just the pointer changing from an arrow to a hand and back again. Real things happened. Hyperlinks changed color; menus dropped down.

As incredible as all of this seemed, the biggest difference came when working with HTML forms. Much of the validation was performed on the client side, right on the browser (which is what client side means, but I was going for the effect here). The fact was that the user no longer had to wait for the entire unload/reload cycle to discover that some moron web developer wants dashes separating the parts of a date instead of forward slashes. This was a real improvement.

In fact, on some websites, techniques were used to prevent the user from entering characters that weren't allowed. If a numeric value is expected in an input box, well, try as you might, only the numeric keys and the decimal point will work; if an integer is expected, users don't even get the decimal point.

Of course, it wasn't long before DHTML was taken to the extreme. On some pages the mouse pointer turned into a magic wand, trailing pixie dust like flies behind a garbage truck. Other web pages seemed to nearly explode whenever the mouse pointer moved because of the sheer number of drop-down menus, rollovers, and assorted "features." Basically, too much of a good thing makes it no longer a good thing.

However, as they say on television, "How'd they do that?"

The quick answer is "Very carefully," but if we we're concerned with quick answers, we would all be millionaires from using a Magic Eight Ball for investment decisions. Of course, this doesn't seem to be working for my broker, so I could be wrong.

The way DHTML works is through a mixture of HTML, Cascading Style Sheets, and JavaScript. Also, as the cooking shows demonstrate, it is all in how the ingredients are put together instead of the fact that they are put together. For example, quite a few people like chicken and chocolate, but with the exception of mole, how many dishes are there that combine the two?

1.2.1. HTML

Yeah, Hypertext Markup Language was what made static web pages work, but just because the web pages were static doesn't mean that HTML was static. Time moved forward, as time usually does, and new capabilities and features were added. Some were, well, not removed, but deprecated, which means that they're still there, but only for compatibility purposes. These deprecated features, however, were more than made up for by the addition of the new features.

The big question is, who decides which features stay, which are deprecated, and which are added? The answer is that all of these decisions are made by the World Wide Web Consortium, which, in secret midnight meetings, dances around a bonfire, drinks mead, and listens to Jethro Tull CDs. Alright, the truth is that committees meet periodically in a conference room and discuss modifications to HTML. However, my explanation accounts for the existence of the marquee tag better than the official explanation.

The World Wide Web Consortium is the governing body that issues "Recommendations" concerning the more technical aspects of the Web. Starting with Hypertext Markup Language version 1.0 and moving through the more current version 4.01 and XHTML version 1.1, the World Wide Web Consortium attempts to keep things standard among the various web browser developers. Theoretically, the end result of these "Recommendations" is that all web browsers behave identically on any specific website, but as I explain later, there are degrees of compliance and interpretation. In addition, there are plenty of nonstandard extensions by browser developers, who, in the hopes of getting a leg up on the competition, continue to add "features" until their browser resembles a Swiss Army knife more than a web browser.

1.2.2. CSS

The problem with HTML is that it was never intended to deal with anything beyond the structure of a page. Unfortunately, early on, somebody new to HTML asked the question, "Hey, how do I make text bold?" and the pure structural language called HTML was polluted by presentation. The end result of this was documents with more HTML than text. Mostly consisting of b tags, i tags, and the dreaded font tags, these documents were a nightmare if it became necessary to make a change.

Cascading Style Sheets, Level 1, are an attempt to bring this situation back under control by providing a way to avoid the b, i, and font tags. Instead, presentation could be dealt with on a per-tag basis, which makes coding somewhat like being a Roman emperor: "The text in the anchor tags amuses memake it bold and Tahoma!"

Cascading Style Sheets work by associating style rules to the elements of an HTML document. These rules can be applied to single tags, tags of a specific type, or developer-specified tags. This eliminates the need to code tags within tags until the page is so bloated that it is nearly impossible to follow; instead, a CSS is specified on the page level or tag level to describe the style for the entire page.

Just in case you're wondering, the cascading part of Cascading Style Sheets comes into play when there is more than one style sheet with rules that can be applied to a specific tag. The specific style sheet rule that is applied depends exactly on how the applicable Cascading Style Sheet is defined. The problem, for me, at least, is remembering cascade sequence. One method of keeping the cascade straight is equating it to something else, something a bit more familiar, as in the winning hands of poker. In poker, the winning hands, from high to low, are:

With Cascading Style Sheets, the "winning" hands are as follows:

As with poker, when there is a winning hand, any other hands are all for naught.

1.2.3. JavaScript

JavaScript is a lightweight, interpreted, object-based programming language that has become the standard client-side scripting language. Based upon the C programming language of Kernighan and Richie fame, JavaScript is how all of those neat and nifty little client-side tricks work. Whether it is event trapping, validation, or whatever, nine times out of ten, JavaScript is the man behind the curtain pulling the levers to make things happen.

Even though JavaScript is widespread doesn't mean that there isn't a lot of confusion about JavaScript. Take, for example, the name; originally called LiveScript, the name was changed to cash in on some of the press that Java was getting early on. To confuse things further, Microsoft sometimes refers to its implementation as JScript, while in Europe, the name ECMAScript is used to refer to JavaScript. I, for one, believe that all of these aliases are designed to hide a gangster past or something along those lines.

Seriously, most of the client-side logic on the Web is coded in JavaScript. This doesn't mean that JavaScript is innately superior to VBScript, Perl, or even Java itself; it is only because JavaScript is built into practically every browser currently available. This means that visitors to websites that use JavaScript, as opposed to any of the alternatives, can jump right into shopping or whatever without waiting for a download to complete.