"Dynamic HTML" is the latest buzzword on the Web. It is supposedly the newest thing, promising to revolutionize both how we surf and how we publish on the Web. So, exactly what is "Dynamic HTML"?
Both Microsoft and Netscape have been proclaiming their specific versions of what they call "Dynamic HTML," although the term has actually been around for quite some time (that is, in "Web time," where "quite some time" is perhaps not quite so long). Dynamic HTML can generically be considered to encompass in some form or fashion all of the following:
CGI (or Common Gateway Interface) scripts have been around since the beginning of HTML. Actually, a CGI script can be a script or a compiled program. The most common language for writing scripts is Perl, although other languages can be used as well. CGI scripts can be used to create animations, error-check form input, provide a query interface to online databases, as well as perform many other tasks. In other words, CGI scripts have been a means for providing "dynamic" content on the Web for quite some time.
The main difference between CGI scripts and the newer scripting languages that are available, such as JavaScript and VBScript, is that CGI scripts are "server-side" scripts, whereas the latter are "client-side" scripts. A server- side script is run from the server, whereas a client-side script is first downloaded to the browser (the client), which then interprets and executes it.
Generally, CGI scripts are stored in a specific directory on a server, most often in a directory named cgi-bin. Because CGI scripts can pose a security hazard to a server, a user has to be given access to the cgi-bin directory--and often scripts must be tested and approved first. Some servers do not allow custom (or user-created) scripts, forcing you to use scripts from their library of stock scripts (such as their stock forms-processing script, and so on).
If you want to find out more about creating CGI scripts, check the following sites:
Return to Top.
Server-side includes (SSI) are similar to CGI scripts and, in fact, can serve as a front-end interface for running CGI programs and scripts. They can also be used to dynamically insert HTML pages inside of HTML pages, allowing frequently changing information to be updated without having to update the whole page. As with CGI scripts, the ability to include SSIs in Web pages usually needs to be enabled by the administration of a server.
Server-side includes are placed in an HTML document by inserting them inside comment tags. The first character (#) alerts the server that the content of the comment is an SSI. The format for server-side includes is shown here:
<!--#argument="value">For more information on using server-side includes, see:
Return to Top.
Client-pull and server-push are a couple of methods developed by Netscape for generating "dynamic" Web pages. In client-pull, the META element (within the HEAD element) is used to direct the browser to refresh the page at a set interval or to automatically load another URL after a set period of time. This is a common method for displaying frames from a video camera (a traffic camera, for instance). A CGI script or some other server-based program runs, converting video frames into the same GIF or JPEG file, which is then refreshed in the browser at a set interval.
Server-push is a method by which the connection between the client (the browser) and the server is held open so the client can be continuously updated by the server. The server then can continually send messages down to the client, instructing it on what actions to perform. One of the problems with this method is that it consumes a server resource (the connection) that might otherwise be available for someone else to use.
For more information on client-pull and server-push see:
Return to Top.
Plug-ins were first introduced by Netscape in their Navigator 2.0 browser and later supported in Microsoft's Internet Explorer 3.0 browser, as well. Prior to plug-ins, what you had instead were "helper applications," which were simply programs that could, say, play a WAV file, or an MPEG file, or view a PCX file, and so on.
Plug-ins, however, are not external applications. Instead, they are tightly integrated with the browser on which they are installed. Also, plug-ins allow many media types to be viewed through a Web page--CorelDraw .CDR files, AutoCad .DXF files, and so on--that would otherwise require the native application.
Probably the most notable contribution of plug-ins in expanding what a Web page can be has been the addition of the ability to include "streaming" media on a Web page. Streaming media can begin playing long before the whole file has been downloaded, whereas regular media must be downloaded in its entirety first. In order to be able to stream these types of media to your browser, a user needs to first download and install the relevant plug-in. Special software might also be required to create the streaming media itself, and additional server support might be required to "serve up" the streaming media.
The following sections describe some of the most popular plug-ins and the URLs for where you can get them.
Shockwave allows streaming of "shocked" sound, animation, and video media. "Shocked" means that the media has been compressed using either Macromedia Director, Authorware, or Flash so that it can then be streamed to the desktop. The plug-in player is free, but the software to create the "shocked" media is not. However, beyond that, no special server support is required. Find out more about Shockwave at:
Macromedia Flash used to be called Future Splash, but it was bought by Macromedia and renamed. Actually, it was renamed again, to Macromedia Shockwave Flash.
Flash allows the display of interactive Web page interfaces, animated buttons, banners, logos, image maps, and more, as well as streaming audio and animation. The Flash player, available free for download, is only 171KB in size. To create Flash sites, a trial version of Flash2 is available for download. Find out more about Flash at:
Progressive Network's RealMedia products, RealAudio and RealVideo, allow inclusion of streaming audio and video in a Web site. The player, RealPlayer, is available free for download. Including RealMedia content on a Web site requires support software that must be installed on the server, and which can be licensed from Progressive Networks (there is a 30-day evaluation version available). Find out more about RealAudio and RealVideo at:
TrueSpeech allows inclusion of streaming audio on a Web site, and no server support software is required. As the name indicates, this is best used to play audio, rather than music files. The TrueSpeech Player is actually not a plug- in, but rather a helper application. It deserves mention here, however, because it offers a free alternative for including streaming audio on a Web site. If you are using Windows 95 or NT, then TrueSpeech audio can be downloaded and played just like any other WAV file (using Media Player). If you download the TrueSpeech Player, you'll be able to listen to TrueSpeech audio in real time.
A number of different ways exist for creating TrueSpeech audio files that can then be included in your Web site--and all of them are free. Windows 95/NT's Sound Recorder can be used to create TrueSpeech WAV files. Alternatively, you can use the DSP Group's conversion software, which is available to be downloaded for free. No server software is required to support delivery of TrueSpeech files, although a server needs to be configured to recognize the TrueSpeech file type. Find out more about TrueSpeech at:
Crescendo allows streaming of MIDI files on streaming-enabled Web sites (requires Crescendo StreamSite). Crescendo Plus allows streaming of MIDI files on all Web sites. Crescendo is free for personal use, whereas Crescendo Plus is available for a yearly subscription fee. Web site authors can provide free streaming MIDI for their users by licensing Crescendo StreamSite (rates vary depending on the type of site). Find out more about Crescendo at:
Return to Top.
A "cookie" is a chunk of data that a Web server can send to a browser, which the browser then stores on the local drive. The next time the user visits that Web site again, the cookie is sent back up to the server--the Web site can then tailor its presentation to the user based on the information included in the cookie. The cookie, itself, might contain just about anything. For instance, you might fill out a form at a site indicating what your interests are that might then be encoded in a cookie and sent back down to your browser so that the next time you visit the site, it would remember what your interests are.
Some people get worried when they find out that Web sites are depositing cookies on their hard drive. Although there is little real cause for alarm relative to cookies, there are a number of relatively minor issues you might want to consider before implementing cookies on your Web site. First, although theoretically cookies deposited by one server on your hard drive should not be able to be read by any other server, there is a slight possibility that a foreign server could "spoof" that server, pretending to be a different server than it really is, and thus gain access to your cookie data from the other server. Still, somebody actually trying to do this, and as far as I know nobody ever has, would be much more likely to be after credit card numbers and the like, which are not likely to be included in a cookie--it's not likely to be profitable, in other words. Second, the only information that will be included in a cookie will be of these sorts: information included in an HTTP request header (such as the originating domain of your request, where you came from, and so on) or information that you, yourself, provided by filling out an online form, for example. A Web site using a cookie cannot grab your e-mail address and resell it--that is, unless you happen to give it to them.
For more information on using cookies, see:
Return to Top.
JavaScript was developed by Netscape and, despite the name, has only a passing resemblance to Java. It allows the inclusion of client-side scripts into Web pages. VBScript (Visual Basic Script) was developed by Microsoft to do the same thing for its browser, Internet Explorer.
Netscape Navigator only supports JavaScript--it does not support VBScript. Internet Explorer not only supports VBScript, but also JScript, which is its implementation of JavaScript. JScript is supposed to be compatible with JavaScript 1.1, but there are differences between the two, specifically in how each apply the Document Object Model (DOM)--the problem is that, although the DOM requirements have largely been agreed upon and set by the W3C, how they should be implemented hasn't been. Therefore, the result still is that a JavaScript 1.1 script that works in Navigator cannot be guaranteed to work in Internet Explorer, and a JScript script can't be guaranteed to work in Navigator. Nice, huh?
Both Netscape and Microsoft, however, have submitted their differences to ECMA (European Computer Manufacturers Association), which is a European standards setting organization, and they have agreed to comply with the resulting standard. The result, ECMA-262, or ECMAScript, has now been released. If both Netscape and Microsoft actually fully comply with this new standard, then maybe we can finally have a JavaScript that will work equally well in both major browsers. In fact, Microsoft has already announced the availability of JScript 3.0, which is supposed to be fully ECMAScript compliant.
See the following sites for more information on using JavaScript (and JScript) and VBScript:
Return to Top.
An "applet" is a client-side application, as compared to a CGI script, for instance, which is a server-side application. Applets are downloaded with a Web page and then entirely executed on the browser's local computer. CGI scripts, on the other hand, are executed on the server, with only the output or result of the script or program actually being sent down to the browser.
Currently, two types of applets can be included in a Web page: Sun Microsystem's Java applets and Microsoft ActiveX applets. Both Netscape Navigator and Internet Explorer support Java applets, but only Internet Explorer supports ActiveX applets.
The main virtue of Java applets is that they are machine independent. Any Java-capable browser can run Java applets, regardless of what platform it is on. ActiveX, on the other hand, is linked to Microsoft's OLE (Object Linking and Embedding) and COM (Component Object Model) technologies, which have to be built into the operating system. ActiveX is not actually a programming language, like Java, but rather a set of rules for sharing data between applications. Several programming languages can be used to create ActiveX applets, including Java, C++, and Visual Basic.
An additional difficulty with ActiveX applets is that they require full access to the local operating system to run, and thus pose an inherent security problem. Microsoft has tried to get around this problem by setting up a system to certificate applet producers (Internet Explorer can then be set to check if the producer of a particular applet is certificated before running the applet). Java applets, on the other hand, in that they require no access to the local operating system, are inherently more secure--you can set in your browser the size of the "sandbox" Java applets will be allowed to play in.
Currently, Microsoft's Internet Explorer supports running both Java and ActiveX applets. Netscape's Navigator only supports running Java applets.
For more information on Java and ActiveX, as well as where you can find free applets to use on your Web site, check out these links:
Return to Top.
The Style tag element was included in the HTML 3.2 specification, but only as a placeholder. Since then, the W3C (World Wide Web Consortium) recommendation for Cascading Style Sheets, Level 1 (CSS1) has been hammered out and included in the draft specification for HTML 4.0.
Cascading Style Sheets allow the attachment of a style sheet to a Web page, as well as the attachment of styles to individual tag elements. The term cascading refers to a fundamental feature of HTML style sheets--that they can cascade. In other words, an author can attach one set of styles, whereas a user can have his or her own personal style sheet, as well, which may or may not override the author's style sheet.
Style sheets are going to be a very big thing on the Web. They provide authors with the ability to control virtually every aspect of how their Web pages will display and appear in a browser, compared to the current HTML model that displays tag elements logically rather than literally. There are those who think this is not such a good thing, believing it will simply encourage more overblown, but content-poor Web pages, while the Web just keeps getting bogged down more and more in a huge cyber-traffic jam. Others, however, feel that this will only be a problem over the short-term and that bandwidth always expands to match demand. Efficient use of style sheets, however, should not add that much of an additional burden to the average HTTP transaction.
Cascading Style Sheets are also the key to both Microsoft's "Dynamic HTML" (DHTML) and Netscape's "dynamic HTML" strategies, as well as to the "event- driven" capabilities that have been added to HTML 4.0. (See the following sections for more information.)
If you want to find out more about Cascading Style Sheets, check out:
Return to Top.
Both Microsoft and Netscape have announced their own versions of what they call "Dynamic HTML." Microsoft claims that its version of Dynamic HTML uses the same cross-platform object model being developed by the W3C and that its implementation does not involve the creation of any additional Microsoft extensions to HTML. Microsoft does, however, lean heavily toward ActiveX and VBScript, which are not the cross-platform solutions that Java and JavaScript are. The other problem is that, although Microsoft claims adherence to the W3C's Document Object Model (DOM), this model is far from being completely ironed out, with many of the outstanding issues being implementation issues.
Netscape, on the other hand, is pushing a combination of its new Layer tag with Cascading Style Sheets, along with "Dynamic Fonts," as what it terms as "dynamic HTML." The idea is that Layers can be used to absolutely position layered objects on a page, as well as to overlap, move, update, and otherwise manipulate Layer contents. Layers can be either transparent or opaque, allowing, for instance, the overlapping of several different graphics, which could then be individually manipulated, moved, changed, and so on.
The problem with Netscape's version of "dynamic HTML" is that the Layer tag has not been accepted by the W3C as part of HTML 4.0 (not yet, anyway). It is a purely Netscape extension to HTML. On the other hand, Netscape otherwise relies on JavaScript and Java in its implementation, which are platform-independent solutions, unlike Microsoft's VBScript and ActiveX solutions.
The Dynamic Fonts aspect of Netscape's implementation of "dynamic HTML" is also not yet part of the HTML 4.0 standard. The main feature of Dynamic Fonts is the ability to download a font description file (or .PRF file) that can then be used by the browser to display the specific font that has been specified. This is different from using the FONT element's FACE attribute, for instance, which depends on a specified font as already being present on the host system. Needless to say, adding multiple font description files to every Web page you create will definitely increase your contribution to the Web's burgeoning traffic jam.
Hopefully, the twain will meet and we'll end up with one single standard for "Dynamic HTML." Since Netscape no longer controls the majority of the browser market, it is highly likely that its version will be established as the de facto standard, as it has often done in the past (with frames, for instance). If a de facto standard is established, it'll probably come from Microsoft, since it has the upper hand in the browser market. The battle is really over two competing visions for the Web, one that sees the future in "thin servers and fat clients," or as a desktop-centric universe (the Web as an extension of the desktop), and the other that sees the future in "fat servers and thin clients," or as a server-centric universe (the desktop as an extension of the Web). In the relatively short term, however, the two competing versions of Dynamic HTML don't seem to me to be absolutely incompatible with each other. HTML has always developed in a somewhat "sloppy" manner, resulting in numerous built-in redundancies.
If you want to find out more about either of the competing versions of Dynamic HTML, check out either of these sites:
Return to Top.
Return to Learn HTML IAW, Revised Edition.
Return to Learn HTML IAW, original edition.
Return to Create Your First Web Page IAW, 3rd Edition.
Return to Create Your First Web Page IAW, Revised Edition.
Return to Create Your First Web Page IAW, original edition.