 |
Chapter 13 |  |
|
Chapter 13 | |
Contents:
Applets
Embedded Content
JavaScript
JavaScript Style Sheets
Truth be told, pure HTML is like a comic book in a world full of Saturday morning cartoons. Save for the occasional animated GIF image, a pure HTML page, although attractive, is a static presentation of text and images. HTML documents need not be limited like the print medium. The Web is a digital dynamo of animation and processing activity, spread over the worldwide Internet. And, with recent innovations, HTML can shimmy, too.
To spice up those otherwise dull pages, a number of HTML tags exist solely to inject dynamic content into your pages. Commonly known as an applet or script, and embedded into the HTML document, these programs get delivered to your browser and executed in any of several different ways. During execution, the applets and scripts may generate dynamic HTML content, interact with the user, validate form data, or even create windows and run entire applications independent of your HTML pages. The possibilities are endless, and go far beyond the document model originally envisioned for HTML.
In this chapter, we describe how dynamic content can augment your HTML documents. We'll show you, with simple examples, how to embed and include executable content--scripts and applets--in your HTML documents. We won't, however, even begin to pretend to teach you how to write and debug your own applet programs. This is a book about HTML, after all. Rather, get an expert opinion: turn to any of the many excellent texts from O'Reilly, including JavaScript: The Definitive Guide, Java in a Nutshell, and Exploring Java.
One of the most exciting recent developments in web technologies is the ability to deliver applications directly to the user's browser, where they are executed on the client machine. These applications are typically small tools--hence the term "applet"--that perform simple tasks on the client computer, including a variety of HTML page display enhancements.
Applets, like client-side image maps, represent a shift in the basic model of web communications. Until recently, servers performed most of the computational work on the Web; client browsers being not much more than glorified terminals. With applets and client-side image maps, Web technology is shifting toward the client, distributing some or all of the computational load from the server to the client and browser.
Applets also represent a way of extending a browser's features without forcing users to purchase or otherwise acquire a new browser, as is the case when developers implement new tag and attribute extensions to HTML. Nor do users have to acquire and install a special application, as is required for helper or plugin applications. This means that once users have a browser that supports applets, you can deliver browser extensions immediately, including HTML display and multimedia innovations.
Applets are like other accessory parts of an HTML document. The browser first loads the HTML page, examines it for special tags that identify applets, which, like other Web resources you identified with a URL, and retrieves the applet via the normal HTTP protocol.
Once downloaded, the browser provides a portion of the document display space for the applet to use as its own display space. You may control the size and position of this display area; the applet controls what is presented inside.
During execution, the applet has access to a restricted environment within the user's computer. For instance, applets have access to the mouse and keyboard, and may receive input from the user. They can initiate network connections and retrieve data from other servers on the Internet. In sum, applets are full-fledged programs, complete with a variety of input and output mechanisms, along with a full suite of network services.
Several applets may be placed in a single document; they all execute in parallel and may communicate with each other. While the browser may limit their access to its computer system, applets have complete control of their virtual environment within the browser.
There are several advantages of applets, not the least of which is providing more compelling user interfaces within a web page. For instance, an applet might create a unique set of menus, choices, text fields, and similar user-input tools different from those available through the browser. When the user clicks a button within the applet's interaction/display region, the applet might respond by displaying results within the region, signaling another applet, or even by loading a completely new page into the browser.
We don't mean to imply that the only use of applets is to enhance the user interface. An applet is a full-fledged program that can perform any number of computational and user-interactive tasks on the client computer. An applet might implement a real-time video display, or perform circuit simulation, or engage the user in a game, and so on.
An applet is nothing more than another tool you may use to produce compelling and useful web pages. Keep in mind that an applet uses computational resources on the client to run and therefore places a load on the user's computer. It can degrade system performance.
Similarly, if an applet uses a lot of network bandwidth to accomplish its task (a real-time video feed, for example), it may make other network communication unbearably slow. While such applications are fun, they do little more than annoy your target audience.
To use an applet correctly, balance the load between the browser and the server. For each page, decide which tasks are best left to the server (forms processing, index searches, and the like) and which tasks are better suited for local processing (user interface enhancements, real-time data presentation, small animations, input validation, and so on). Divide the processing accordingly. Remember that many users have slower network connections and computers than you do and design your applets to satisfy the majority of your audience.
Used the right way, applets seamlessly enhance your pages and provide a satisfying experience for your audience. Used improperly, applets are just another annoying bandwidth waster, alienating your users and hurting your pages.
Creating applets is a programming task, not usually a job for the HTML author, and certainly way beyond the scope of this book. For details, we recommend you consult any of the many applet programming texts that have recently appeared on bookshelves everywhere, including those from O'Reilly & Associates.
Today, one language dominates the applet programming world: Java. Developed by Sun Microsystems of Mountain View, California, Java supports an object-oriented programming style wherein classes of applets can be used and reused to build complex applications.
By invention, applets built from the same language should run with any browser that supports them. In reality, certain Microsoft implementation decisions have caused some valid Java applets to fail when running on Internet Explorer. Hopefully, Microsoft will fix these problems and Java will remain a universal programming language for the Web. In any case, the conscientious Java programmer should keep abreast of the latest technology and create applets that are certifiably 100% pure Java. Microsoft, in particular, is trying to get programmers to use proprietary extensions to Java that will work on only Microsoft platforms. We recommend avoiding any vendor extensions to Java that deviate from the standard Java 1.1 version currently in widespread use.
We should take this opportunity to also mention ActiveX, an alternative applet programming technology available only from Microsoft. ActiveX is proprietary, closely coupled to various versions of Microsoft Windows, and is only fully functional when used with Internet Explorer. ActiveX applets will run on versions of Internet Explorer targeted to various versions of Windows, but a single ActiveX applet will not run on these different versions without recompilation. This is in contrast with Java applets, where a single Java applet can be written and compiled once and immediately run on a broad range of browsers and operating systems.
ActiveX also presents an unacceptably high security risk to any user whose browser supports ActiveX technology. It is ridiculously easy to penetrate and damage a computer running a browser that allows ActiveX applets to be executed. For this reason, we cannot recommend ActiveX as a viable applet implementation technology and we go so far as to recommend that users disable ActiveX capability within their browser--specifically, Internet Explorer.
Use the <applet> tag within your HTML document to name the applet that the browser should download and execute. Also, use the tag to define a region within the document display for the applet's display area. You may also supply alternative content within the <applet> tag for display by browsers that do not support applets.
Code is the only required attribute. It identifies the class name of the Java program.
The browser inserts the applet display region into the containing text flow exactly like an inline image: without line breaks and as a single large entity. The browser downloads and executes the applet just after download and display of the HTML document, and continues execution until the code terminates itself or when the user stops viewing the page containing the applet.
Most applets require one or more parameters that you supply in the HTML document to control their execution. Put these parameters between the <applet> tag and its corresponding </applet> end tag using the <param> tag. The browser passes the document-specific parameters to the applet at time of execution. [the section called "The <param> Tag"]
Like an image, you may control the alignment of an applet's display region with respect to its surrounding text. In fact, the <applet> tag's align attribute honors all the alignment values used by the <img> tag, including top, texttop, middle, absmiddle, baseline, bottom, and absbottom, as well as left and right alignments for wrap-around content. [the section called "The align attribute"]
The alt attribute gives you a way to tell users gracefully that something is missing if, for some reason, the applet cannot or will not execute on their computer. Its value is a quote-enclosed message string that, like the alt attribute for images, gets displayed in lieu of the applet itself.
The alt message is only for browsers that support applets. See 13.1.5.11 to find out how to inform users of applet-incapable browsers why they can't view an applet.
Supported only by Netscape, the archive attribute lets you collect common Java classes into a single library that is cached on the user's local disk. Once cached, the browser doesn't need to use the network to access an applet; it retrieves the software from the local cache, thereby reducing the inherent delays of additional network activity to load the class.
The value of the archive attribute is a URL identifying the archive file. The suffix of the archive filename may be either .zip or .jar. .zip files are in the familiar ZIP archive format, generated by PKZIP and many other utilities. .jar files are in the new Java archive format; currently, support for .jar files is spotty at best, but they will become more widespread. .jar files support compression and some advanced features like digital signatures.
You may use the archive attribute with any <applet> tag, even if the class referenced by the tag's code attribute does not exist in the archive. If the class is not found in the archive, the browser simply attempts to retrieve the class relative to the document URL or the codebase URL, if specified.
The code attribute is required. Use it to specify the filename of the Java class to be executed by the browser. Note that this is not a URL; the browser assumes the applet file is in the same directory as the host HTML document. To make the search relative to another storage location, use the codebase attribute described in 13.1.5.5 or an archive, as described above. Also, the extension suffix of the filename should be .class. If you don't include the suffix, some browsers automatically will append .class when searching for the applet.
For example, to execute a clock Java applet contained in a file named clock.class, you might include in your HTML document the code:
<applet code=clock.class> </applet>
The browser will locate the code for the applet using the current document's base URL. Hence, if the current document's URL is:
http://www.kumquat.com/harvest_time.html
the browser will retrieve the applet code for our clock class example above as:
http://www.kumquat.com/clock.class
Use the codebase attribute to provide an alternative base URL from which the browser will retrieve an applet file. The value of this attribute is a URL pointing to a directory containing the class defined by the code attribute. The codebase URL overrides, but does not permanently replace, the document's base URL, which is the default if you don't use codebase. [the section called "Referencing Documents: The URL"]
Continuing with our previous examples, suppose your document came from http://www.kumquat.com, but the clock applet is kept in a separate directory named classes. You cannot retrieve the applet by specifying code=classes/clock.class. Rather, include the codebase attribute and new base URL:
<applet code=clock.class codebase="http://www.kumquat.com/classes/"> </applet>
which resolves to the URL:
http://www.kumquat.com/classes/clock.class
Although we used an absolute URL in this example, you also can use a relative URL. For instance, in most cases the applets are stored on the same server as the host HTML documents, so we'd usually be better off, for relocation's sake, specifying a relative URL for the codebase, such as:
<applet code=clock.class codebase="/classes/"> </applet>
The name attribute lets you supply a unique name for this instance of the code class--the copy of the applet that runs on the individual user's computer. Like other named elements in your HTML document, providing a name for the applet lets other parts of your HTML document, including other applets, reference and interact with this one, such as sharing computed results.
For example, suppose you have two clock applets in your document, along with two applets the user operates to set those clocks. Provide unique names for the clock applets using the name attribute, then pass those names to the setting applets using the <param> tag, which we discuss later in this chapter:
<applet code=clock.class name=clock1> </applet> <applet code=clock.class name=clock2> </applet> <applet code=setter.class> <param name=clockToSet value=clock1> </applet> <applet code=setter.class> <param name=clockToSet value=clock2> </applet>
Since we have no need to distinguish between the Setter applets, we choose not to name their instances.
Identical to the counterparts for the <img> tag, the height and width attributes define the size of the applet's display region in the document. They both accept values indicating the size of the region in pixels. [the section called "The height and width attributes"]
The display region's dimensions often must match some other applet requirement, so be careful to check these values with the applet programmer. Sometimes, the applet may scale its display output to match your specified region.
For example, suppose our example clock applet should grow or shrink to fit nearly any size display region. Hence, we might create a square clock 100 pixels wide by 100 pixels tall:
<applet code=clock.class height=100 width=100> </applet>
As with a floating or inline image, surrounding text tightly abuts an applet's display region. The hspace and vspace attributes let you interpose some empty space around the applet region to set it off from the text. Both attributes accept a value that indicates pixels of space, with the hspace attribute creating a space to the left and right of the region; the vspace attribute adds space above and below the region.
For instance, to give our example clock some breathing room on the page, we might place an additional five pixels of space around it:
<applet code=clock.class height=100 width=100 hspace=5 vspace=5> </applet>
The mayscript attribute, supported only by Netscape, indicates that the Java applet will be accessing JavaScript features within the browser. Normally, Java applets attempting to access JavaScript cause a browser error. If your applets access JavaScript, you must specify mayscript in the <applet> tag.
The value of this attribute is a quoted string, which is used by Internet Explorer to provide a title, if necessary, for the applet. This attribute is not supported by Netscape.
Since some browsers may not support applets or the <applet> tag, sometimes you may need to tell readers what they are missing. You do this by including HTML body content between the <applet> and </applet> tags.
Browsers that support the <applet> tags ignore the HTML content inside. (Use the alt attribute to notify applet-enabled browser users when the applet doesn't display for some reason.) Of course, browsers that don't support applets don't recognize the <applet> tags. Being generally tolerant of apparent HTML mistakes, they will usually ignore the unrecognized tag and blithely go on to display whatever content may appear inside. It's as simple as that. The following fragment tells applet-incapable browser users they won't see our clock example:
<applet code=clock.class> If your browser were capable of handling applets, you'd see a nifty clock right here! </applet>
Remember that this contained text is different from the text supplied by the alt attribute of the <applet> tag. The alt text is displayed by browsers that support the <applet> tag but cannot execute or display the specified applet. The contained text is displayed by browsers that do not support the <applet> tag at all. In order to accommodate both classes of browsers, the considerate author supplies both for each <applet> tag:
<param>
<applet code=clockclass height=100 width=100 alt="[ Clock applet not available ]"> <param name=style value=analog> If your browser were capable of handling applets, you'd see a nifty analog clock right here! </applet>
The <param> tag supplies parameters for a containing <applet> or <object> tag.
[the section called "The <object> Tag"]
The <param> tag has no content and no end tag. It appears, perhaps with other <param> tags, only between an <applet> or <object> tag and its end tag. Use the <param> tag to pass parameters to the applet program or embedded object as required for it to function correctly.
The <param> tag has two required attributes: name and value. Both attributes accept strings as their value and together define a name/value pair that the browser passes to the applet.
For instance, our Clock applet example might let users specify the time zone by which it sets its hour hand. To pass the parameter named "timezone" with the value "EST" to our example applet, you would specify the parameters as:
<applet code=clock.class> <param name=timezone value=EST> </applet>
Since both attributes had simple strings for values, we did not enclose the values in quotation marks. For values with embedded punctuation and spaces, be sure to delimit the strings accordingly.
The browser will pass the name/value pairs to the applet, but that is no guarantee that the applet is expecting the parameters, that the names and values are correct, or that the applet will even use the parameters. Correct parameter names, including capitalization, and acceptable values are determined by the applet author. The wise HTML document author will work closely with the applet author or have detailed documentation to ensure that the applet parameters are named correctly and assigned valid values.
The type and valuetype attributes are supported only by Internet Explorer. Use them to define the type of the parameter the browser passes to the embedded object and how that object is to interpret the value. Used only with <param> tags contained within an <object> tag (see 13.2), these attributes have no use with parameters being passed to Java applets.
The valuetype attribute can have one of three values: data, ref, or object. The value data indicates that the parameter value is a simple string. This is the default value. Using ref indicates that the value is a URL of some other resource on the web. Finally, object indicates that the value is the name of another embedded object in the current document. This may be needed to support inter-object communication within an HTML document.
The value of the type attribute is the MIME media type of the value of the parameter. This is usually of no significance when the parameter value is a simple string, but can be important when the value is actually a URL pointing to some other object on the Web. In those cases, the embedded object may need to know the MIME type of the object in order to use it correctly. For example, this parameter tells the embedded object that the parameter is actually the URL of a Microsoft Word document :
plug-ins
<param name=document value=http://kumquats.com/quat.doc type=application/msword valuetype=url>
|
 |
|
| Named Frame or Window Targets |  |
Embedded Content |
