Let me jump back to the music metaphor for a minute. If you already know how to play the piano, then you can understand the guitar quickly. But understanding is one thing -- playing well is another. To play well, you still need to learn how to strum, flatpick, and adapt the chords you know from the keyboard to the fretboard.
As a result, the "language" taken as a whole is fairly large, and requires a great deal of effort to learn in its entirety. Few programmers are familiar with the entire range of possibilities inherent in the language, and it's common for scripts written by one programmer to rely on an entirely different set of features than those written by another.
lynx -source http://example.com/some.js.
document.all, DHTML Behaviors) that presented this Faustian bargain: offering greatly enhanced functionality, but to a restricted audience, often targeting a single browser version.
And after all of that, even if you were lucky enough to learn one or both of the Netscape LAYERS DOM and Microsoft Internet Explorer's
document.all DOM; time, audience, and budgetary constraints often forbid the full exploration of either DOM in the name of compromises and cross-browser workarounds.
On the other hand, if you were unlucky enough to have experimented with Dynamic HTML in the 4.x generation, you may have decided on your own that the lowest common denominator between the two major DOMs was too low for any useful applications. Some who reached this decision abandoned one or the other, in favor of whatever DOM offered the more powerful feature set for their needs. Still others simply gave up on DHTML as a platform for applications, and stuck to enhancing traditional web sites with UI and navigation hacks or primarily design-oriented uses.
As is the case with dynamic web sites of all kinds, the need to use server-side logic to manage cross-browser and cross-platform compatibility issues has added an extra level of complexity that many simply wished to avoid. The need to use PHP, mod_perl, Cold Fusion, ASP, and various other environments to produce or deliver code optimized to the target browser of the moment was a hurdle few wanted to deal with.
Tied to the browser by way of Document Object Models of varying quality and depth of implementation, the trend is nonetheless strongly toward cross-platform, cross-browser compatibility and standards compliance (though you will likely have to work a bit to figure out which 90 percent of the standard is supported in which browser, and jury-rig the rest).
simply cut the value of the SRC link and paste it into the Location: field of your browser (making adjustments for path information, as necessary). In many newer browsers, this will display the source intact, rather than running it.
If your browsing platform of choice is Navigator, use the "view-source:" pseudo-protocol as a prefix to the URL you created from the SRC value, to display the source. If you're on Unix/Linux, you can use the "lynx" text-mode browser to capture web files to local disk (use the
Once you've had a chance to dig in a bit, find a forum suitable to your tastes (whether Usenet newsgroup, BBS, mailing list or digest, or even chat) and start asking questions. Some forums have more stringent conventions with respect to the amount of work you are expected to have done on your own before asking for help, but most, if not all, expect you to provide a useful level of detail regarding your problem or question.
Steve Champeon is a recognized developer, author, and editor specializing in Web technologies. At his "day job," he serves as the CTO of hesketh.com, a Web services firm in Raleigh, NC.
Copyright © 2009 O'Reilly Media, Inc.