Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or @retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of @United States copyright laws. For information, address Que Corporation, 201 West 103rd Street, Indianapolis, IN 46290 or at support@mcp.com.

Notice: This material is excerpted from Special Edition Using HTML, 2nd Edition, ISBN: 0-7897-0758-6. This material has not yet been through the final proof reading stage that it will pass through before being published in printed form. Some errors may exist here that will be corrected before the book is published. This material is provided "as is" without any warranty of any kind.

Chapter 15 Netscape-Specific Extensions to HTML

by Mark Brown

The first thing you usually find out about any computing standard is that it's not really very standard at all. Programmers are an imaginative, inventive, and egotistical lot. Their usual attitude toward someone else's idea of how things should be done is "I can do it better." Then they proceed to prove that, indeed, they can. As a result, you get many computer games that bypass the computer's operating system completely, so you can get swarmed by 1,000,000 aliens per second instead of a mere 999,997. Unfortunately, these games usually don't work at all - that is, they are "busted" - on the next generation of PCs. In fact, they probably don't work on some not insignificant percentage of this generation of personal computers.

All of which brings us indirectly to HTML. The official HTML standard is up to version 2.0 now. However, when it was still at version 1.0, most of the browser programs cruising the Web supported a good portion of the "proposed" 2.0 @HTML standard already. Why? Because the features were so cool and HTML 1.0 was so lame in comparison that no one could stand to wait for the 2.0 standard to become, well, standard.

Of course, even before @HTML 2.0 was declared the new standard, dozens of proposals were floating around the Web for new features for @HTML 3.0. Again, people could not wait to start jamming keen new features into their browser programs - and even began adding a few more of their own invention along the way. The bright, innovative, cutting-edge programmers at Netscape were, as usual, right there leading the pack. Therefore, many extensions to @HTML are built into the latest version (2.0) of @Netscape Navigator. In this chapter, you learn about the ways in which Netscape extends the HTML standard.

Should You Use Browser-Specific Extensions?

Many new Web developers wonder whether they should use browser-specific tags, or whether they should stick with the HTML standard. It's a tough call.

Some could argue "Yes, you should go ahead and use browser-specific tags because they are so flashy and cool and make your pages look and perform so much better." This argument makes a lot of sense, especially if you're talking about Netscape Navigator. After all, the most recent Web usage statistics say that over 80 percent of the people cruising through your Web site will be using Netscape anyway. If you can grab their attention by making good use of all the nifty new Netscape features such as frames and Sun's Java, maybe they'll be more likely to stick around and find out what you have to say.

Then, too, if you want to get technical, even widely used capabilities such as tables and background images are still only "proposed" @HTML 3.0 features. They're not official yet. But just try to imagine how boring the Web would be if everyone avoided these features just because they don't conform to some "official" standard. And, though Netscape pioneered support for background images and tables, it didn't take long for other browsers such as Mosaic and Microsoft Internet Explorer to add them, too.

On the other hand, you could also easily answer "No, you shouldn't use browser-specific extensions." If you write only for Netscape Navigator, what about the 20 percent who don't use it? And remember that even among Netscape users, not everyone is running the latest version of the program. In fact, as of this writing version 1.1 is still the most popular version of Netscape (although 2.0 is gaining market share rapidly). Until most everyone has made the switch, even many Netscape users may look at your fancy new pages and say "Huh?"

Perhaps the major "anti" argument is this: What are standards good for if nobody follows them? A well-established precedent exists for suggesting and approving enhancements to @HTML. The IETF (Internet Engineering Task Force) handles the situation democratically through a process that allows anyone on the Web - from giants such as Microsoft and Netscape to little guys like you and me - to propose and comment on changes and additions for each iteration of the HTML standard. If you're, say, a huge publisher of Web browser software, and you just go ahead and implement your own ideas of what HTML should be like, isn't that like wresting power from everyone else?

That point of view is probably pretty cynical. In truth, Netscape and @Microsoft and the other browser vendors are really trying to improve what the Web is, how it works, and what it can do. Standards committees move slowly, as do all bureaucracies. The way of the corporation has always been to throw a product into the marketplace and see if anyone buys it.

And people are buying both @Netscape Navigator and the @HTML enhancements that come with it. Netscape Corporation's financial reports prove the former; the proliferation of Web pages that use @Netscape 2.0 extensions prove the latter (see fig. 15.1).

Fig. 15.1

You'd expect Netscape's own site to be overflowing with cool examples of Netscape 2.0's latest and greatest extensions to HTML, and it is.

Of course, there is room for compromise. Many of the @Netscape HTML extensions closely match @HTML 3.0 proposals. If you stick to a syntax that is supported by both, you shouldn't have any trouble keeping compatible with most of the browsers on the Web, both now and in the near future.

Do you need to be afraid of using the @Netscape HTML extensions discussed in this chapter on your @Web pages? Probably not. But before you do, ask yourself whether by doing so you would be alienating a good portion of your audience, or whether you would be drawing in more viewers to your site. As always, if you keep your goals in mind, the answer should be clear.


Style Sheets: the Big Difference

Many of @Netscape's HTML extensions differ from the proposed @HTML 3.0 standard in one big, important way. Netscape has implemented many page formatting options as custom @HTML tags; @HTML 3.0 proposes to handle formatting via a technique called style sheets. Style sheets are meant to separate presentation style from @HTML structure. In other words, they are meant to keep HTML from becoming a page definition language rather than the page description language it was originally intended to be.

Style sheets will carry a Web designer's presentation preferences in a separate definition (a style sheet). The viewers could, if using browsers that support style sheets, choose to view the page using either the Web designer's preferences or their own, as defined in their browsers' setups.

Apparently, style sheets are definitely going to be in the @HTML 3.0 standard, and future versions of @Netscape Navigator are likely to support both types of page formatting.


For more information on the topic of Netscape 2.0 versus HTML 3.0, including side-by-side comparisons of how they perform similar tasks, point your browser to the following:

http://webreference.com/html3andns/introduction.html

Netscape Version 1.1 HTML Extensions

Netscape hasn't just begun mucking around with @HTML recently. Ever since version 1.1, they have included HTML extensions in Navigator. Version 1.1 included many extensions that have become widely popular on the Web. Many made it into the @HTML 2.0 standard, and many more are solid for inclusion in @HTML 3.0.

Table 15.1 lists some of the more important @HTML innovations that Netscape included in @Navigator version 1.1.

Table 15.1 - Extensions to @HTML introduced in @Netscape Navigator 1.1.

Tag Change(s) Function
BASEFONT New Specifies base font size
BLINK New Blinks text
BODY BACKGROUND Tiles background graphic on page
BR CLEAR Waits for clear margin before break
CENTER New Centers page elements
FONT New Specifies font size or +/ - base size
HR SIZE Specifies rule thickness
WIDTH Specifies rule length
ALIGN Left, center, or right alignment
NOSHADE No shading
IMG ALIGN Left, center, or right alignment
WIDTH Specifies image width
HEIGHT Specifies image height
BORDER Specifies image border width
VSPACE Specifies space above and below image
HSPACE Specifies space left and right of image
ISINDEX PROMPT Text input field prompt
LI TYPE Changes type of index
VALUE Changes value in ordered lists
NOBR New Allows no breaks in marked block
OL TYPE Specifies counter type
START Specifies counter start value
UL TYPE Specifies bullet shape
TABLE New Creates tables (uses additional tags such as TD, TC, TR, and so on)
WBR New Allows word break in NOBR section

Of the @Netscape version 1.1 additions listed in table 15.1, tables are so important and in such widespread use that this book devotes the entirety of chapter 13 to them. The changes to the BODY and HR tags, as well as the new CENTER, BASEFONT, and FONT tags, are all discussed in this chapter. The other @Netscape version 1.1 HTML extensions have been around long enough and are so universally used that they are simply covered in context in the appropriate chapters of this book.

See [chapter 13] "Tables and Equations"

Netscape Version 2.0 HTML Extensions

In keeping with tradition, Netscape added several new ground-breaking features to @HTML in version 2.0 of Navigator, and made a few changes to some of the old, familiar tags. Table 15.2 lists the major @HTML extensions implemented in @Netscape Navigator 2.0.

Table 15.2 - Extensions to @HTML introduced in @Netscape Navigator 2.0.

Tag Change Function
A TARGET Opens new target display window
BASE New Defines a default window
DIV ALIGN Aligns elements left, right, or center
EMBED New Embeds live objects (video and so on)
FORM ENCTYPE HTTP file upload for forms
FRAMESET New Creates frames (uses additional tags FRAME and NOFRAMES)
IMG USEMAP Creates a client-side imagemap (uses additional tags MAP and AREA)
META --- Implements client pull
--- Implements international character sets
P ALIGN Aligns text left, right, or center
SCRIPT New Executes a JavaScript applet
TEXTAREA WRAP Specifies word wrap in forms

All the changed and new tags listed in table 15.2 are discussed in this chapter except Java and JavaScript.

Because frames are the biggest, newest kid on the block, I talk about them first.

Frames

Everywhere you surf on the Net these days, you find sites all gussied up with frames - at least, you do if you're using a frames-capable browser such as Netscape 2.0. Frames create independently changeable and (sometimes) @scrollable windows that tile together to break up and organize a display so that is not only more visually appealing but also easier to work with. Figure 15.1, earlier in this chapter, presented an example of the real-world use of frames at @Netscape's own Web site.

Frames are similar in many ways to @HTML tables. If you understand how tables work, frames will be second nature to you.

However, unlike tables, frames not only organize data, but they also organize your browser's display window. In fact, they break up the window into individual, independent panes or frames. Each frame holds its own @HTML file as content, and the content of each frame can be scrolled or changed independently of the others. In a way, each frame almost becomes its own "mini-browser."

At this point, take a look at an entire block of @HTML markup code that creates a @frame document of medium complexity:

<HTML>
<HEAD>
</HEAD>
<FRAMESET ROWS="25%,50%,25%">
<FRAME SRC="header.htm">
<FRAMESET COLS="25%,75%">
<FRAME SRC="label.htm">
<FRAME SRC="info.htm">
</FRAMESET>
<FRAME SRC="footer.htm">
</FRAMESET>
<NOFRAMES>
Your browser cannot display frames.
</NOFRAMES>
</HTML>

This example produces the frames page shown in figure 15.2. As you can see, this @HTML code produces four frames. The top frame spans the page and includes a header. The page also has two central frames, one for a label on the left, which takes up 25 percent of the screen width, and one for information on the right, which takes up the remaining space. Another frame fills the entire width of the bottom of the screen and contains a footer.

Fig. 15.2

The @frame document produced by the example @HTML code, as displayed by @Netscape Navigator 2.0.

The FRAMESET Container

Frames are contained in a structure called a FRAMESET, which takes the place of the @BODY container on a @frames-formatted Web page. A @Web page composed of frames has no @BODY section in its @HTML code, and a page with a @BODY section cannot use frames.

If you define a BODY section for a page that you compose using FRAMESET and FRAME commands, the @frame structure is completely ignored by browser programs, and none of the content contained in the frames is displayed.

Because no BODY container exists, FRAMESET pages can't have background images and background colors associated with them. (They are defined by the BACKGROUND and BGCOLOR attributes of the BODY tag, respectively.)

Make sure that you don't accidentally use BODY and FRAMESET on the same page.

The <FRAMESET></FRAMESET> container surrounds each block of frame definitions. Within the FRAMESET container, you can have only @FRAME tags or nested @FRAMESET containers.

The FRAMESET tag has two attributes: ROWS and COLS (columns). Here's a fully decked-out (but empty) generic FRAMESET container:

<FRAMESET ROWS="value_list" COLS="value_list">
</FRAMESET>

You can define any reasonable number of ROWS or COLS, or both, but you have to define something for at least one of them.

If you don't define more than one row or column, browser programs ignore your FRAMES completely. Your screen is left totally blank. In other words, you can't have a FRAMESET of just one row and one column - which would just be a single window, anyway. If you define at least two ROWS or COLS, however, you can safely omit the other attribute and a value of 100% is assumed for it.

The "value list" in the @generic FRAMESET line is a comma-separated list of values that can be expressed as pixels, percentages, or relative scale values. The number of rows or columns is set by the number of values in their respective value lists. For example, the following defines a frame set with three rows:

<FRAMESET ROWS="100,240,140">

These values are in absolute number of pixels. In other words, the first row is 100 pixels high; the second, 240 pixels high; and the last, 140 pixels high.

Setting row and column height by absolute number of pixels is bad practice, however. It doesn't allow for the fact that browsers run on all kinds of systems on all sizes of screens. Although you might want to define absolute pixel values for a few limited uses - such as displaying a small image of known dimensions - a better practice is to define your rows and columns using percentage or relative values like this:

<FRAMESET ROWS="25%,50%,25%">

This example creates three frames arranged as rows, the top row taking up 25 percent of the available screen height; the middle, row 50 percent; and the bottom row, 25 percent. If the percentages you give don't add up to 100 percent, they are scaled up or down proportionally to equal 100 percent.

Proportional values look like this:

<FRAMESET COLS="*, 2*, 3*">

The asterisk (*) defines a proportional division of space. Each asterisk represents one piece of the overall "pie." You get the denominator of the fraction by adding up all the asterisk values (if no number is specified, 1 is assumed). In this example, the first column would get 1/6 of the total width of the window, the second column would get 2/6 (or 1/3), and the final column would get 3/6 (or 1/2).

Remember that bare numeric values assign an absolute number of pixels to a row or column, values with a % (percent sign) assign a percentage of the total width (for COLS) or height (for ROWS) of the @display window, and values with an * assign a proportional amount of the remaining space.

Here's an example using all three in a single definition:

<FRAMESET COLS="100, 25%, *, 2*">

This example assigns the first column an absolute width of 100 pixels. The second column gets 25 percent of the width of the entire @display window, whatever that is. The third column gets 1/3 of what's left, and the final column gets the other 2/3. Absolute pixel values are always assigned space first, in order from left to right. They are followed by percentage values of the total space. Finally, proportional values are divided up based on what space is left.

Remember, if you do use absolute pixel values in a COLS or ROWS definition, keep them small so that you are sure they'll fit in any browser window, and balance them with at least one percentage or relative definition to fill the remainder of the space gracefully.

If you use a FRAMESET with both COLS and ROWS attributes, it creates a grid of frames. Here's an example:

<FRAMESET ROWS="*, 2*, *" COLS="2*,*">

This line of @HTML creates a @frame grid with three rows and two columns. The first and last rows each take up 1/4 of the screen height, and the middle row takes up half. The first column is 2/3 as wide as the screen, and the second is 1/3 the width.

You can nest <FRAMESET></FRAMESET> sections inside one another, as you saw in the initial example. But that's getting ahead of the game. You need to look at the FRAME tag first.

The FRAME Tag

The @FRAME tag defines a single frame. It must sit inside a FRAMESET container, like this:

<FRAMESET ROWS="*, 2*">
<FRAME>
<FRAME>
</FRAMESET>

Note that the FRAME tag is not a container so, unlike FRAMESET, it has no matching end tag. An entire @FRAME definition takes place within a single line of @HTML code.

You should have as many FRAME tags as spaces are defined for them in the FRAMESET definition. In this example, the FRAMESET established two rows, so you need two FRAME tags. However, this example is boring because neither of the frames has anything in it! (Frames like these are displayed as blank space.)

The FRAME tag has six associated attributes: SRC, NAME, MARGINWIDTH, MARGINHEIGHT, SCROLLING, and NORESIZE. Here's a complete generic FRAME:

<FRAME SRC="url" NAME="window_name"SCROLLING=YES|NO|AUTO MARGINWIDTH="value" MARGINHEIGHT="value" NORESIZE>

Fortunately, frames rarely use all these options.

The most important @FRAME attribute is SRC (source). You can (and quite often do) have a complete FRAME definition using nothing but the SRC attribute, like this:

<FRAME SRC="url">

SRC defines the @URL of the content of your frame. It is usually an HTML format file on the same system, so it usually looks something like this:

<FRAME SRC="sample.htm">

Note that any @HTML file called by a frame must be a complete @HTML document, not a fragment. Therefore, it must have HTML, HEAD, and BODY containers, and so on.

Of course, the source can be any valid URL. If, for example, you want your frame to display a GIF image that is located somewhere in Timbuktu, your FRAME might look like this:

<FRAME SRC="http://www.timbuktu.com/budda.gif">

If you specify a URL that the browser can't find, the frame is created but left empty and you get a nasty error message from Navigator. Note that the effect is quite different than that produced by simply specifying a FRAME with no SRC at all. <FRAME SRC="unknown URL"> creates a frame but leaves it blank; <FRAME> is not created at all - the space is allocated and left completely empty, with no frame around it.

You cannot use plain text, headers, @graphics, and other elements directly in a @FRAME document. All the content must come from @HTML files as defined by the @SRC attribute of the FRAME tags. If any other content appears on a FRAMESET page, it is displayed, and the entire set of frames is ignored.

The @NAME attribute assigns a name to a frame that can be used to link to the frame, usually from other frames in the same display. The following example creates a frame named Joe:

<FRAME NAME="Joe">

The @Joe frame can be referenced via a hyperlink like this:

<A HREF="http://www.yoursite.net" TARGET="Joe">Click Here to Jump to Joe</A>

Note the TARGET attribute that references the name of the frame.

If you don't create a name for a frame, it simply has no name. All frame names must begin with an alphanumeric character.

MARGINWIDTH and MARGINHEIGHT give you control over the width of the frame's margins. They both look like this:

MARGINWIDTH="value"

The value is always a number and always represents an absolute value in pixels. For example, the following creates a frame with top and bottom margins 5 pixels wide, and left and right margins 7 pixels wide:

<FRAME MARGINHEIGHT="5" MARGINWIDTH="7">

Remember, the topic is margins here, not borders. MARGINWIDTH and MARGINHEIGHT define a space within the frame within which content does not appear. Border widths are set automatically by the browser, not your HTML code.

Your frames automatically have scroll bars if the content you've specified for them is too big to fit the frame. Sometimes having scroll bars ruins the aesthetics of your page, so you need a way to control them. That's what the SCROLLING attribute is for. Here's the format:

<FRAME SCROLLING="yes|no|auto">

SCROLLING has three valid values: Yes, No, and Auto. Auto is assumed if no SCROLLING attribute appears in your FRAME definition. Yes forces the appearance of a scroll bar. No keeps them away at all costs. For example, this FRAME definition turns on scroll bars:

<FRAME SCROLLING=YES>

The user can normally resize frames. If you move the mouse cursor over a frame border, it turns into a resize gadget that lets you move the border where you want it. Doing so always mucks up the look and feel of your beautifully designed frames. You therefore always should use the NORESIZE attribute to keep users from resizing your frames. Here's how:

<FRAME NORESIZE>

That's it. No values. Of course, when you set NORESIZE for one frame, none of the adjacent frames can be resized, either. Depending on your layout, using NORESIZE in a single frame is usually enough to keep users from resizing all the frames on the screen.

NOFRAMES

"All of this is well and good," you say, "and I really want to use these keen new features on my Web pages. But I can't help feeling guilty about all those users who don't have frames-capable browsers. They won't be able to see my beautiful pages!"

Don't worry. Here's where you can provide for them, too.

The <NOFRAMES></NOFRAMES> container is what saves you. By defining a NOFRAMES section and marking it up with normal HTML tags, you can provide an alternate Web page for users without forms-capable browsers. Here's how it works:

<NOFRAMES>
All your HTML goes here.
</NOFRAMES>

You can safely think of this example as an alternative to the BODY structure of a normal Web page. Whatever you place between the <NOFRAMES> and </NOFRAMES> tags will appear on browsers without frames capability. Browsers with frames will throw away everything between these two tags.

Some Frame Examples

Frames are very flexible, which means they can get complicated fast. This section presents a few examples of real-world frame definitions.

The simplest possible frame setup is one with two frames, like this:

<HTML>
<HEAD>
</HEAD>
<FRAMESET ROWS="*, 2*">
<FRAME SRC="label2.htm">

<FRAME SRC="info.htm">
</FRAMESET>
</HTML>

This code defines a page with two frames, organized as two rows. The first row takes up 1/3 the height of the screen and contains the @HTML document label2.@htm, and the second takes up the other 2/3 and contains the document info.htm. Figure 15.3 shows how Netscape displays this page.

Fig. 15.3

Netscape displays the simple two-row FRAMESET defined by the example @HTML code.

You could just as easily create ten rows, or use the same syntax substituting the COLS attribute to create two (or ten) columns. However, ten columns or rows are too many for any browser to handle gracefully. Your pages should never have more than three or four rows or columns.

If you want to display more information than three or four rows or columns, you should probably use tables rather than frames. Remember, frames are most useful when you want to add an element of control in addition to formatting the display. Tables are best if all you want to do is format data.

A regular rectangular grid of rows and columns is just about as easy to implement:

<HTML>
<HEAD>
</HEAD>
<FRAMESET ROWS="*, 2*" COLS="20%, 30%, 40%">
<FRAME SRC="labela.htm">
<FRAME SRC="labelb.htm">
<FRAME SRC="labelc.htm">
<FRAME SRC="info.htm">
<FRAME SRC="info.htm">
<FRAME SRC="info.htm">
</FRAMESET>
</HTML>

This example creates a grid with two rows and three columns (see fig. 15.4). Because you defined a set of six frames, you provide six FRAME definitions. Note that they fill in by rows. That is, the first FRAME goes in the first defined column in the first row, the second frame follows across in the second column, and the third finishes out the last column in the first row. The last three frames then fill in the columns of the second row, going across.

Also note that the math didn't work out very well, because the percentage values in the COLS definition add up to only 90 percent. No problem, as the browser has adjusted all the columns proportionally to make up the difference.

Fig. 15.4

This 2 by 3 grid of frames was created by the @HTML example.

A bit tougher is the problem of creating a more complex grid of frames. For that, return to the example that opened this section:

<HTML>
<HEAD>
</HEAD>
<FRAMESET ROWS="25%,50%,25%">
<FRAME SRC="header.htm">
<FRAMESET COLS="25%,75%">
<FRAME SRC="label.htm">
<FRAME SRC="info.htm">
</FRAMESET>
<FRAME SRC="footer.htm">
</FRAMESET>
<NOFRAMES>
Your browser cannot display frames.
</NOFRAMES>
</HTML>

The output of this file was shown in figure 15.2.

This example makes use of nested FRAMESET containers. The outside set creates three ROWS, with 25 percent, 50 percent, and 25 percent of the window height, respectively:

<FRAMESET ROWS="25%,50%,25%">

Within this definition, the first and last rows are simple frames:

<FRAME SRC="header.htm">
...
<FRAME SRC="footer.htm">

Each of these rows runs the entire width of the screen. The first row at the top of the screen takes up 25 percent of the screen height, and the third row at the bottom of the screen also takes up 25 percent of the screen height.

In between, however, is this nested FRAMESET container:

<FRAMESET COLS="25%,75%">
<FRAME SRC="label.htm">
<FRAME SRC="info.htm">
</FRAMESET>

This FRAMESET defines two columns that split the middle row of the screen. The row these two columns reside in takes up 50 percent of the total screen height, as defined in the middle row value for the outside @FRAMESET container. The left column uses 25 percent of the screen width, and the right column occupies the other 75 percent of the screen width.

The FRAMEs for the columns are defined within the set of @FRAMESET tags, which include the column definitions, whereas the @FRAME definitions for the first and last rows are outside the nested @FRAMESET command but within the exterior FRAMESET in their proper order.

This code is not as confusing if you think of an entire nested FRAMESET block as a single FRAME tag. In the example, the outside FRAMESET block sets up a situation in which you have three rows. Each must be filled. In this case, they are filled by a FRAME, then a nested FRAMESET two columns wide, and then another FRAME.

By now (if you are a programming-type person) you may be asking yourself, "I wonder if it is possible for a FRAME to use as its SRC a document that is, itself, a FRAMESET?" The answer is yes. In this case, you simply use the FRAME tag to point to an HTML document that is the FRAMESET you would have otherwise used in place of the FRAME.

Let me restate the preceding example (which used nested FRAMESETs) in terms of referenced FRAME documents instead. Of course, this example takes two HTML files instead of one because you're moving the nested FRAMESET to its own document. Here's the first (outside) file:

<HTML>
<HEAD>
</HEAD>
<FRAMESET ROWS="25%,50%,25%">
<FRAME SRC="header.htm">
<FRAME SRC="frameset.htm">
<FRAME SRC="footer.htm">
</FRAMESET>
<NOFRAMES>
Your browser cannot display frames.
</NOFRAMES>
</HTML>

And here's the second file, which is called @frameset.htm:

<HTML>
<HEAD>
</HEAD>
<FRAMESET COLS="25%,75%">
<FRAME SRC="label.htm">
<FRAME SRC="info.htm">
</FRAMESET>
</HTML>

In this case, the top and bottom rows behave as before. But the second row is now just a simple FRAME definition like the others. However, the file that its SRC points to is frameset.htm, which you just created with a FRAMESET all its own. When this file is inserted into the original FRAMESET, it behaves just as if it appeared there verbatim. The resulting screen is identical to the original example (see fig. 15.5).

Fig. 15.5

Though identical to figure 15.2, this screen was generated by different HTML code.

Although you can create nested FRAMESETs using FRAME tags that call the same URL, doing so certainly isn't a good idea. This process is called @infinite recursion, and creates an @infinite loop in a computer, consuming all memory and crashing the machine. Fortunately, frames-aware browsers check for this problem - if a SRC URL is the same as any of its ancestors it's ignored, just as if no SRC attribute existed at all.

By using nested FRAMESET containers in clever combinations, you can create just about any grid of frames you can dream up. But remember that you're trying to create a friendly, useful interface, not show off how clever you can be with frames.


Navigating a Site with Frames

You need to know three things about navigating through a site that uses frames.

  1. The Back button doesn't back you out of a frame; it backs you out of the whole FRAMESET to the previous page. To back out of a frame, first point your mouse pointer to the frame you want to back out of. Then click the right mouse button (the Mac has only one button, so use it). You get a pop-up menu and can select Back in Frame.
  2. If you're in a window with frames, and you move to one that's outside the FRAMESET, your frames disappear. They return if you use the Back button.
  3. You can bookmark a frame by choosing @Add Bookmark for This Link from the same pop-up menu mentioned in @Point 1. If you simply choose Add Bookmark from your browser's main menu, you get a bookmark for the original FRAMESET, which may not be exactly where you are now.


Targeted Windows

Sometimes when you're browsing the Web, you want to keep a window open showing where you were while you go to someplace new. That way, you don't have to press the Back button a zillion times to return to your starting place - you just close the newer window and your old one is there waiting for you unchanged. You've always been able to open a new browser window in Netscape by choosing File, New Web Browser from the Navigator menu, or by pressing Ctrl+N.

But what if you want to keep somebody else's browser window open to your home page while a link from your site sends that user off to somewhere else? That way, when the user is done, all he or she has to do is click on the Close button in the window he or she is in, and the user then drops right back to the window displaying your page.

Before Netscape Navigator 2.0, a Web page designer couldn't do that. But with 2.0's targeted windows, it's easy. All you have to do is add a TARGET attribute to a link, like this:

<A HREF="URL" TARGET="window_name">Click Here.</A> 

TARGET names the browser window to use when jumping to the specified URL. If a window with that name doesn't already exist, the browser opens a new window and calls it by the @TARGET name.

If you don't feel like adding TARGETs to every link on your site, an associated new BASE tag lets you name the default target window for all links that do not have explicit TARGETs. Its format is

<BASE TARGET="base_target"> 


Allowed Names for Targeted Windows

For a TARGET window, you can use any name that is alphanumeric. Anything else is ignored, except for a few reserved names. Any window name that begins with the following names is treated as though it has the reserved name (that is, _selfish is the same as _self). Note that each reserved name begins with an underscore character (_):

_blank tells the browser to open a new untitled window in which to display the specified URL.

_self always opens a link in the same window from which it was called.

_parent opens a link in the previous window. If there is no previous window, it acts like _self.

_top opens a link in the main browser window.


Embedded Objects

Multimedia is exciting, but Web browsers just aren't built for it. Since the beginning of the Web, people have had to call upon external helper applications to display video, audio, and foreign @graphics files. With the advent of Netscape's new plug-ins capability, however, multimedia has become integrated into the browser itself.

A plug-in is essentially a specially written code module that integrates seamlessly into your browser. For example, a Netscape plug-in for playing @MPEG movies would, once installed, allow Netscape to display @MPEG movies inline, without your having to launch an external helper application. This capability is exciting because it makes Netscape infinitely expandable and means that @multimedia content may finally become commonplace on the Web.

Just to give you some idea of what's going on, here is a quick overview of a few of the plug-ins that have been announced for Netscape:

Fig. 15.6

Plug-ins allow live, interactive content to appear in the Netscape window, like this Macromedia Director concentration game on the Toy Story Web site.

For these new plug-ins, you can present live objects inline on a Web page by using the new EMBED tag. Here is a typical use:

<EMBED SRC="video.avi" WIDTH=100 HEIGHT=200 AUTOSTART=TRUE LOOP=TRUE>

This line of @HTML code embeds a @Video for @Windows movie called video.avi in place on the Web page. When the page is displayed, the plug-in that is configured for playing .avi files launches invisibly in the background. The WIDTH and @HEIGHT attributes create a playback area 100 pixels wide and 200 pixels high in the browser window. The @AUTOSTART=TRUE command starts the video playing automatically, and the @LOOP=TRUE attribute indicates that the @video should play in a loop until stopped. These EMBED tag attributes are defined for a specific fictional plug-in. Each real plug-in has its own attribute syntax, defined by the plug-in publisher.

If you plan to support Netscape plug-ins on your Web pages, you have to find out the EMBED tag attributes for specific viewers. Netscape maintains a @Web page with links to plug-ins developers. You can access it by choosing Help, About Plug-ins from the Navigator 2.0 menu.


Coming Soon: LiveMedia

Plug-ins and the EMBED tag aren't Netscape's last word on inline multimedia. LiveMedia is a new framework for bringing real-time audio and video inline into Netscape. @Netscape Corporation says that LiveMedia will make live audio, video-on-demand, video conferencing, Internet telephony, and other real-time on-line applications practical.

Eleven companies have initially signed on to support Netscape LiveMedia: Progressive Networks, Adobe Systems, Digital Equipment Corp., Macromedia, NetSpeak, OnLive!, Precept, Silicon Graphics, VDOnet, VocalTec, and Xing. These companies will provide inline applications based on the @Internet Realtime Transport Protocol (RTP) and other open audio and @video standards such as MPEG.

Netscape is publishing the @LiveMedia framework on the @Internet, will license key technology components of it, and hopes to get it adopted as a formal Internet standard.


Dynamic Documents

Server push and client pull are @Netscape 2.0's innovative new techniques for automatically updating @Web pages. Here are just a few uses for these "dynamic documents":

Though server push and client pull do similar things, they differ completely in how they work.

Server push is accomplished by running a @CGI program on a @Web server system, and is beyond the scope of this chapter. Server push differs from other @CGI programs only in that server push applications keep a connection open from the server to the browser and "push" a stream of data at the browser. Server push is often used for data-driven applications such as animating icons, though it is rapidly being replaced for such purposes by Java applets.

Client pull, on the other hand, is implemented using the <META> tag and a browser capable of performing it, such as Netscape 2.0. Compared to server push, client pull is relatively easy to set up. It requires no special CGI scripts or special programming; all the work is done by Netscape. Here's how it's done.

You can use the META tag only in the HEAD section of a Web page, like this:

<HTML>
<HEAD>
<META HTTP-EQUIV="Refresh" CONTENT="30; URL=newpage.htm">
</HEAD>
<BODY>
Please wait 30 seconds for the next page.
</BODY>
</HTML>

This example displays the message Please wait for 30 seconds for the next page. Then the magic in the META tag starts. The @HTTP-EQUIV="Refresh" attribute tells Netscape to load a new page. The @CONTENT attribute contains two values separated by a semicolon. The first, which is numeric, tells Netscape how long to wait in seconds before performing the Refresh action. The URL=newpage.@htm value tells Netscape the URL of the a page to load when the time has expired.

Though simple in its implementation - and somewhat obscure in @syntax - client pull is a powerful new @Netscape addition to @HTML.

@Netscape 2.0 also incorporates a second extension to the @META tag. It allows MIME charset information to be contained in an HTML document. Here's the syntax:

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-2022-JP"> 

This extension makes it easier to create Web pages for an international audience because the specified character set can be for any language in the world (this particular example is for Japanese).

Java Applets and JavaScript

@Java is an exciting new cross-platform @programming language from @Sun Microsystems; it brings a new kind of power to the Web. Java-capable browsers such as @Netscape 2.0 can run @Java applet programs to create animations, automatic presentations, @interactive games, and other dynamic pages.

@Java and the @Netscape scripting language based on @Java, JavaScript, are such important new Web capabilities that this book devotes a whole chapter to the topic. Turn to chapter 26 for an in-depth examination.

Client-Side Imagemaps

With each new @generation of browser programs and with each update to the @HTML standard comes an increased effort to bring the exciting capabilities once reserved for CGI programmers down to humble @HTML coders.

One of the prettiest and most functional features of the best pages on the Web is the @clickable imagemap. Unfortunately, in the past this useful and eye-appealing tool has been reserved for those who can write server-side CGI-bin programs. Now all that has changed. @Netscape 2.0 has wrested the @clickable imagemap from the hands of the lofty CGI-bin programmers and given it to the people by implementing client-side @imagemaps.

The great thing is that client-side @imagemaps work exactly the same as server-side @imagemaps. Their implementation is transparent to the user. However, you can easily create client-side imagemaps by using just a couple of new HTML tags.

Though server-side and client-side @imagemaps look and act alike, they are implemented completely differently. With server-side maps, the server does all the work. With client-side maps, the browser does it all. Chapters 11 and 12 cover in detail how server-side maps work.

Imagemaps allow users to select URLs (local or distant) by clicking on specific areas of a displayed image. Different areas are "mapped" to different URLs. Hopefully, the designer provides some sort of @visual cue in the graphic to indicate to the user which areas lead to which locations.

A client-side @imagemap consists of two parts: the graphic map image itself (a GIF or JPEG file) and the @MAP definition that defines which areas lead to which URLs. Here's the generic usage of the MAP tag:

<MAP NAME="mapname">
<AREA [SHAPE="shape"] COORDS="x,y,..." [HREF="URL"] [NOHREF]>
</MAP>

Note that, as with <FRAMESET> and <FRAME>, <MAP> is a container and has a corresponding </MAP> tag, and <AREA> is simply a stand-alone tag.

Here's an example of a full client-side imagemap definition:

<MAP NAME="menu">
<AREA SHAPE="RECT" COORDS="0,0,99,49" HREF="Item1.htm">
<AREA SHAPE="RECT" COORDS="100,0,200,49" HREF="Item2.htm">
<AREA SHAPE="RECT" COORDS="200,0,299,49" HREF="Item3.htm">
</MAP>
<IMG SRC="menu.gif" USEMAP="#menu">

Figure 15.7 shows the @Web page created by this @HTML code.

Fig. 15.7

The client-side @imagemap produced by the example @HTML code.

The @MAP container defines and names the @imagemap. In this example, the NAME attribute is set to "menu", so that is the name of the map. You reference this name later from the IMG tag.

A client-side @imagemap is made up of @AREA tags. Each AREA tag sets the "hot spot" for a link. For example, the first AREA tag

<AREA SHAPE="RECT" COORDS="0,0,99,49" HREF="Item1.htm">

defines a clickable region within the image that has 0,0 as its upper-left coordinate (in pixels) and 99,49 as its lower-right corner coordinate. This @AREA tag defines the @HREF link for its @clickable area as the local @URL Item1.htm.

The @SHAPE attribute defines the shape of the @clickable area. Table 15.3 lists the four currently allowed @SHAPE definitions, along with the formats for entering coordinates for each.

Table 15.3 - Allowable SHAPE attributes for the AREA tag.

Shape SHAPE="" COORDS=""
Rectangle RECT x upper left, y upper left, x lower right, y lower right
Polygon POLY x1, y1, x2, y2,... xn, yn
Circle CIRCLE x center, y center, radius
Default DEFAULT not specified - entire bitmap

The syntax is such that you may add other shapes to the definition when browsers support them. If the SHAPE tag is absent, SHAPE="RECT" is assumed. If two AREAs overlap, the first one defined is active for the shared area.

The HREF="URL" attribute points to the link, just as it does with a regular HTML link. In place of the HREF="" attribute, you can use NOHREF to indicate that an area is dead, or unclickable. By default, any areas not specifically designated are assumed to point nowhere anyway. But NOHREF can come in handy, especially when you're designating all leftover areas with the DEFAULT value for SHAPE, if you specifically want to exclude some area or areas from being clickable.

All relative links are considered to be relative to the document containing the @MAP definition tags, not the one containing the referring USEMAP element, if different. If a @BASE tag appears in the document containing the @MAP description, that URL is used.

The final line of the example shows how to reference a MAP after it's built:

<IMG SRC="menu.gif" USEMAP="#menu">

This @IMG tag loads the image called menu.gif, which is the image you've been reading about all along. The new @USEMAP attribute is what makes client-side @imagemaps work. It references the name defined for the @imagemap way back in the first line of code. Remember this line?

<MAP NAME="menu">

This particular USEMAP reference is to "#menu" because the MAP definition is in the same document as the reference to it. However, the MAP definition (as well as the SRC image, of course) can be anywhere. All you need is a valid URL as the value in the USEMAP="" reference.

Surprisingly, you can define an imagemap that works as both a client-side and a server-side map. All you have to do is combine the two definitions. Here's the syntax:

<A HREF="/cgi-bin/binfile"> <IMG SRC="map.gif" USEMAP="#map" ISMAP></A>

If the browser supports client-side @imagemaps, the map in the USEMAP definition is used. If not, the @ISMAP attribute causes the @CGI program binfile to be run on the server.

If you want to use client-side maps but can't write CGI programs, and you're worried about non-Netscape users stumbling over your maps, here's a graceful way to take care of them: give 'em a page with an alternate menu! Here's the syntax:

<A HREF="textmenu.htm"> <IMG SRC="menu.gif" USEMAP="menu"> </A> 

When the user clicks the image, this code sends a non-Netscape user to a new page, textmenu.htm, where you have thoughtfully provided a text menu.


Other Changes to the IMG (Image) Element

Though client-side @imagemaps are arguably the most exciting addition to the @IMG tag, Netscape 2.0 has made several other important enhancements to it.

For each of the following attributes, "n" is a dimension expressed in number of pixels.

    ALIGN

    This new attribute is discussed later in this chapter because it also applies to other tags.

    WIDTH

    Specifies the image width. WIDTH="n".

    HEIGHT

    Specifies the image height. HEIGHT="n".

    BORDER

    Specifies the image border width. BORDER="n".

    VSPACE

    Specifies the space above and below the image. VSPACE="n".

    HSPACE

    Specifies the space to the left and right of the image. HSPACE="n".

    ISMAP

    Allows the image to be used as a clickable server-side imagemap. This important feature has all of chapters 11 and 12 devoted to it.

An example of using all the attributes for the @IMG tag could look something like this:

<A HREF="/cgi-bin/mapfile"><IMG SRC="map.gif" WIDTH="120" 
HEIGHT="135" ALIGN=ABSMIDDLE BORDER=2 VSPACE=4 HSPACE=7 ISMAP></A> 

But don't despair. Most images don't use all the allowed IMG tag attributes, just a few.


Background Graphics and Color

Two extensions to the @BODY tag allow the @Web page designer to define @tileable background graphics and custom background colors for @Web pages. Though these extensions originated in Netscape, most browsers now support them. Here's an example:

<BODY BACKGROUND="background.gif" BGCOLOR="#FFFFFF"

The @BACKGROUND attribute fills the background of the browser window with the specified @graphic image file. If the image is smaller than the page (hopefully!), it is tiled to fill the window.

Because @graphics take a long time to transmit over the @Internet (especially over modem connections), it is best to be sparing with backgrounds. Fewer colors and smaller images work best. Then, too, you often experience a problem with contrast. Because the page @graphics and text are overlaid on the background image, a gaudy or non-contrasting background image can make it hard to see the page elements. Still, when done well, background @graphics can add a lot of flash and @eye appeal to your @Web pages.

The BGCOLOR attribute lets you define a background color. This action is completely independent from specifying a BACKGROUND image. In fact, if you do both, the background color doesn't appear at all (unless your background image is a transparent GIF, in which case it shows through the "holes").

The value assigned to the @BGCOLOR attribute is generally expressed as a six-digit @hexadecimal value that specifies the @RGB (Red, Green, Blue) values for the color you want. Unfortunately, specifying colors is a lot more like rocket science than art.


All about Hexadecimal RGB Values

Take a moment to learn about RGB values now because the subject pops up time after time in programming - even HTML programming.

@Computer screen colors are expressed in @RGB (Red, Green, Blue) values because a @TV set or @computer monitor builds up a color image from red, green, and blue @phosphor dots. You can create all colors by mixing these three in varying intensities.

You can make over 16 million different colors by combining R, G, and B values with intensities expressed as numbers in the range from 0 - 255, with 0 meaning none of that color at all, and 255 meaning the maximum amount of that color possible. For example, a color value of R=128, G=128, and B=0 makes a medium yellow because red and green (without any blue) makes yellow, and you are mixing each of them at about half of their possible maximum intensities.

The reason you use a range of 0 - 255 is that it just happens to be the range represented by 8 bits, or 1 byte. 00000000 (8 bits in computer binary) is decimal 0, and 11111111 is decimal 255. But @computer people like to break up a byte into two smaller chunks called @nybbles. Each contains four bits, and 1111, the maximum value for a nybble, is equal to 15 in decimal. However, computer people also like to represent a nybble as a single character. The digits 0 - 9 are no problem, but 10 - 15 take two digits to represent, so the letters A - F are substituted. This substitution is called hexadecimal notation. So A=10, B=11, and so on. This means you count 0 - 9, A - F, and then go into two digits.

The upshot is that, if you're numbering from 0 - 255 in decimal, you go from 00 to FF in hexadecimal. So a color value of #FF55DD, for example, means a @Red value of FF (hexadecimal) or 255 (decimal), a Green value of 55 (hex) or 85 (decimal), and a Blue value of DD (hex) or 221 (decimal).

Many calculators can automatically convert between decimal and @hexadecimal numbers. Even the lowly Windows calculator will do. Just select View, Scientific from the Windows Calculator menu. To convert from decimal to hexadecimal, first make sure the Dec button is selected, and then enter a decimal number and click the Hex button. To convert from hex to decimal, reverse the process: click the Hex button first, enter your hex number, and then click the Dec button.


Thankfully, there is an alternative to using hexadecimal color values. Netscape recognizes an exhaustive table of 140 predefined color values. You can, for example, say BGCOLOR="black", and you get a black screen. Table 15.4 lists the color values Netscape has built in. (I am not making this up, though I think someone at Netscape Corporation spent way too much time looking at the names on sample chips at the local paint store.)

@Table 15.4 - Netscape's 140 Custom Colors

aliceblue forestgreen navajowhite
antiquewhite *fuchsia *navy
*aqua gainsboro oldlace
aquamarine ghostwhite *olive
azure gold olivedrab
beige goldenrod orange
bisque *gray orangered
*black *green orchid
blanchedalmond greenyellow palegoldenrod
*blue honeydew palegreen
blueviolet hotpink paleturquoise
brown indianred palevioletred
burlywood indigo papayawhip
cadetblue ivory peachpuff
chartreuse khaki peru
chocolate lavender pink
coral lavenderblush plum
cornflowerblue lawngreen powderblue
cornsilk lemonchiffon *purple
crimson lightblue *red
cyan lightcoral rosybrown
darkblue lightcyan royalblue
darkcyan lightgoldenrodyellow saddlebrown
darkgoldenrod lightgreen salmon
darkgray lightgrey sandybrown
darkgreen lightpink seagreen
darkkhaki lightsalmon seashell
darkmagenta lightseagreen sienna
darkolivegreen lightskyblue *silver
darkorange lightslategray skyblue
darkorchid lightsteelblue slateblue
darkred lightyellow slategray
darksalmon *lime snow
darkseagreen limegreen springgreen
darkslateblue linen steelblue
darkslategray magenta tan
darkturquoise *maroon *teal
darkviolet mediumaquamarine thistle
deeppink mediumseagreen tomato
deepskyblue mediumslateblue turquoise
dimgray mediumspringgreen violet
mediumblue mediumturquoise wheat
mediumorchid mediumvioletred *white
mediumpurple midnightblue whitesmoke
dodgerblue mintcream *yellow
firebrick mistyrose yellowgreen
floralwhite moccasin

The 16 color names understood by @Microsoft Internet Explorer 2.0 are indicated with an asterisk (*). @NCSA Mosaic does not support named colors.

You can have only one background image and color set per page.

If the users have turned off Auto Load Images in their browsers, they won't see your background images. So don't count on those images being there.

Netscape 1.1 had a bug that allowed multiple changing background colors. It was widely abused, and they thankfully left this "feature" out of Netscape 2.0.

You cannot define background images or colors for individual table cells or frames. Individual frames can, however, load documents that contain their own separate background image or color, which is defined in the @BODY tag of the document.

One big problem you can get into when setting your own background images and colors is that your page text is often lost in the resulting melange. Hopefully, you're putting more thought than that into your selection of backgrounds and colors, but if you really want to go with something wild - or if you just want to set a color mood - you also can use new BODY attributes to change the colors of your page text.

TEXT specifies the color of normal text; LINK defines the color for links; and VLINK modifies the color of previously visited links. With all these BODY tags in use, here's what a typical BODY element might look like:

<BODY BACKGROUND="wheatfield.gif" BGCOLOR="wheat" TEXT="#ddeeff" LINK="papayawhip" VLINK="mistyrose">

Forms Enhancements

Forms are ubiquitous on the Web. It seems like wherever you go, you're always filling out a form. It's almost as bad as real life.

Fortunately, Netscape has added a couple of innovations to @HTML forms to make them a bit easier to use.

HTTP File Upload

You've seen them on the Web: huge forms with a zillion fields. Credit applications. Personality tests. Opinion polls. You can sit there paying for connect time for hours while you fill them out. There has to be a better way.

With HTTP file upload, there is. @HTTP file upload lets a @Web page creator give his or her users the option to compose a form data file offline and upload the form information all at once. This process takes only a few seconds, saving connect time and money.

This trick is accomplished through a new value for the @FORM tag ENCTYPE attribute, which specifies the @MIME type of a form. In the past, only one valid value existed for ENCTYPE: application/x-www-form-urlencoded. The new value defined for input files is multipart/form-data.

Here's an example of a short form that accepts file input (see fig. 15.8):

<FORM ENCTYPE="multipart/form-data" 
ACTION="http://www.site.com/cgi-bin/getfile" METHOD=POST>
File to process? <INPUT NAME="file1" TYPE="file">
<INPUT TYPE="submit" VALUE="Send File">
</FORM>

Fig. 15.8

A short example of a @Web form that accepts a file as input.

The new INPUT TYPE="file" not only lets you upload a file in response to the form request, it even adds a BROWSE button that, when clicked, brings up a standard file requester dialog box.

Of course, the @FORM ACTION specifies a @CGI-bin program (called "getfile" in the example) to parse the information from the file, and you need to tell people somewhere on your @Web page exactly what the program expects in the way of data and formatting (or better yet, provide a template for downloading) so that your users can prepare a proper data file. Otherwise the whole process breaks down. Unfortunately, it all means that HTTP file upload is only for those who can write the CGI programs to support it. But at least it should make long forms easier to use for all.

TEXTAREA Wrap

The TEXTAREA tag for forms lets you specify a scrolling text box of a specified size for lengthy text fields. The problem is, if you keep typing, the box keeps scrolling sideways.

Now Netscape has added the ability to turn on word wrap in these boxes via a new @WRAP attribute for the @TEXTAREA tag. Here's how it looks:

<TEXTAREA WRAP=OFF|VIRTUAL|PHYSICAL>

@WRAP=OFF turns off text wrap (this is the default, and the way it was before). WRAP=VIRTUAL turns on word wrap as far as the display is concerned but still sends the data to the server as one long line. @WRAP=PHYSICAL actually splits text input into the same size chunks it displays on-screen.

Character Attributes

Once upon a time, you didn't have much control over the way text looked on your @Web pages. Those days are gone. Besides the @font color definitions now allowed in the @BODY tag, Netscape has added text blink and on-the-fly @font color and size changing to @HTML.

BLINK

Rumors are flying that Marc Andreeson, founder of Netscape, has said that the BLINK tag was meant to be a joke. If so, it has been one of the most successful jokes in history, to judge by how much it is used on the Web.

Although huge blocks of blinking text can be annoying, the occasional judicious use of a blinking word to draw the viewer's attention to a critical item of information can be useful. The @BLINK tag works just like all text markers. You surround the text you want blinking with these tags:

<BLINK>This blinks.</BLINK>

Whatever is between the tags blinks. Actually, it varies at a steady rate (on my machine about every 3 seconds, but your mileage may vary) between the defined text color and the defined background color or image, unless overridden by the user's browser settings.

Font Size and Color

@Netscape's new FONT tag lets you specify both the font color and size for a block of text rather than for the entire page, as you must do using the various text attributes of the BODY tag.

The FONT tag works like all other text formatting tags - you surround the text you want to change. This example uses the new COLOR attribute:

We've got <FONT COLOR="tomato">color text</FONT> now! 

Here the message color text appears in the Netscape predefined color called @tomato. You can, of course, also specify colors in hexadecimal, as with the @BODY tag attributes discussed previously in this chapter.

You can also change @font size with the @FONT tag using the @SIZE attribute. Netscape assumes a default base @font size with (what seems to be) an arbitrary numerical value of 3. The @FONT SIZE tag can specify a new absolute @font size, or an increment or decrement to the base size. A new tag called @BASEFONT sets the base size to something other than 3. Here is an example of their use:

<BASEFONT=2>
<FONT SIZE=4>I'm bigger than base.</FONT>
<FONT SIZE=+3>I'm bigger yet.</FONT>

The @BASEFONT line changes the size of the base @font from its default size of 3 to a new value of 2. The first @FONT SIZE line prints the message I'm bigger than base. in a font size of 4. The second @FONT SIZE line increments the base @font size by 3, resulting in a font size of 5 for the message I'm bigger yet. Any normal text printed after the final </FONT> appears in the new base font size of 2.

@Fonts can have any size from 1 to 7. If any combination of BASEFONT or @FONT SIZE elements results in numbers lower or higher than these, they are set to 1 or 7, respectively.

Of course, you can also use a single set of FONT tags to change both color and size, like this:

<FONT SIZE=7 COLOR="purple">I'm big and purple.</FONT>

You can go really crazy changing font size and color with every word or even every character, but don't. Although you might want to make these changes for occasional fun or even maybe to create an interesting logo, I'd sure hate to see a lot of "ransom note" pages where every character is a different size and color.

CENTER and ALIGN

Early Web pages had all the elements aligned along the left margin, with no way to arrange them nicely on the page. (And text didn't even wrap around @graphics!) Fortunately, that has all changed.

The new CENTER tags let you center whatever appears between them, like this:

<CENTER>
This text is centered.<BR>
So is this image:<IMG SRC="centered.gif"><BR>
</CENTER>

That's it. You can now center just about everything quickly and easily.

The new ALIGN attribute for the IMG (image), P (paragraph), Hn (heading), HR (horizontal rule), and DIV (division) tags allows a flexible new range of alignment options for each. They all work in the same manner, though the @IMG tag allows a wider range of options. Table 15.5 lists the values that you can assign to the ALIGN attribute.

Table 15.5 - @Valid values for the ALIGN attribute for IMG, P, Hn, HR, and DIV tags.

Value Valid For Syntax
LEFT IMG,P,Hn,HR,DIV Aligns with left margin
RIGHT IMG,P,Hn,HR,DIV Aligns with right margin
CENTER IMG,P,Hn,HR,DIV Centers between margins
TOP IMG Aligns the top of the image with the top of the tallest item in line
TEXTTOP IMG Aligns the top of the image with the tallest text in line
MIDDLE IMG Aligns the middle of the image with the baseline of the current line
ABSMIDDLE IMG Aligns the middle of the image with the actual middle of the current line
BOTTOM, BASELINE IMG Aligns the bottom of the image with the bottom of the line
ABSBOTTOM IMG Aligns the bottom of the image with the absolute bottom of the current line, including text descenders

Here are some real-world examples:

<P ALIGN=CENTER>Centered text paragraph</P>
<H1 ALIGN=RIGHT>Right Aligned Heading</H1>
<HR ALIGN=CENTER>
<IMG SRC="somepic.gif" ALIGN=ABSBOTTOM>
<DIV ALIGN=LEFT><IMG SRC="otherpic.gif">Here's a picture.</DIV>

The first line centers a paragraph of text consisting of the single sentence @Centered text paragraph. The next line right-aligns the @Heading 1 text Right Aligned Heading. Line three creates a centered horizontal rule. The fourth line of code aligns the image somepic.gif with the absolute bottom of the text surrounding it; that is, with the lowest point of text descenders like lowercase g and p. The final line left-aligns the image otherpic.gif and the accompanying text Here's a picture.

With all these new alignment options available, @Web pages are starting to look a lot better.

Horizontal Rules

You can use horizontal rules to break up text into nice eye-sized chunks. Unfortunately, they are rather boring, which is why so many sites use long, skinny, colorful GIF images instead of HTML's HR tag.

Netscape has modified the HR tag with four attributes that help break the monotony: SIZE, WIDTH, ALIGN, and NOSHADE. ALIGN was discussed previously in this chapter. SIZE specifies a rule's thickness in pixels. WIDTH defines the width in pixels if the value assigned to it is an unadorned number, and a percentage of the screen width if the value is followed by a percentage sign. ALIGN aligns a rule to LEFT, RIGHT, or CENTER. (If the rule hasn't been shortened using the WIDTH command, all are equivalent.) Finally, NOSHADE creates a rule without the default shadow.

Here is an example that uses all four attributes:

<HR SIZE=4 WIDTH=75% ALIGN=CENTER NOSHADE>

This example creates a horizontal rule that is 4 pixels thick, 75 percent as wide as the browser display, centered, without shading.

That's it for Netscape extensions to HTML. The next chapter covers extensions introduced by other browser programs (mostly Microsoft Internet Explorer) as well as some proposed @HTML 3.0 tags not implemented by Netscape.


Internet & New Technologies Home Page - Que Home Page
For technical support for our books and software contact support@mcp.com
© 1996, Que Corporation