7. How can I keep my Web pages robust?
A very convenient feature of HTML is that browsers will ignore tags that they don't understand. This means that it is easy to predict what all older browsers will do in the presence of a new tag, so that it is possible to make correct decisions about whether, and how, to use new tags.
As you browse the Web with a modern graphical browser, you will see many pretty pages, whose authors have done things you will be tempted to emulate. In many cases, however, you will find that you must make a compromise between page designs that are pretty on some browsers, but fragile (and therefore ugly or non-functional on other browsers), and robust page designs whose appearance may be more "sturdy and functional" than "elegant." Often you will find that for a comparable or only slightly greater initial effort, it will be possible to create page designs that are both robust and elegant.
As you make your choices about the design of your pages, you should keep clearly in mind the user population you expect to be serving; for example:
Additional information on the demographic characteristics of a large population of Web surfers and their hardware and software can be found on-line at the Georgia Tech survey page; look particularly at the most recent survey.
This method takes more learning at the start, because you must confront the raw HTML, but there are no concealed assumptions, so you retain complete control.
This method provides a good quick transition from an existing written document to put it on the Web, but the resulting page will almost always be riddled with fragilities because of the word processor's assumptions.
This method is quick, and once you learn the ins and outs of the particular software package will usually let you produce a robust page, but you are still vulnerable to the software's hidden assumptions.
The title should be reasonably terse, descriptive of the contents, with neither acronyms nor obscure abbreviations, and unique (at least among all the pages controlled by that author). It is often a good idea to include the organization's name for official pages. It is both trite and also redundant with its own existence to use the phrase "home page" in either the title of the Web page, or in the first header in the body of the page.
Often, but not always, it will be sensible to choose identical text for the TITLE and for the first-level header at the top of the document, or for the displayed text of a banner graphic at the top of the document.
The height and width specification will speed up display of your page, because the browser can continue to lay out the text without waiting for the image file to be returned by the server.
The ALT text should be specified on every image, so that Lynx users (and graphical browser users with image loading turned off) are informed (if there is text) or not distracted by the default "[image]" text (which will be suppressed by having an empty string or space character for the ALT text, as opposed to having no ALT text at all).
Server-side imagemap support is, by definition, server-specific. Most servers are configured to use either CERN or NCSA format for the imagemap data file. Consult with the system manager of your server to learn how it should be done. You might also want to take a look at the on-line documentation we provide for Ohio University Web authors, for a discussion of methods to use server-side imagemaps. That discussion includes step-by-step instructions for preparing the imagemap data files in either CERN or NCSA format.
If you type in information that others are responsible for knowing as part of their job, then your pages will not start out broken, but they will be out of date sooner, more often, and for longer times. One of the daunting aspects of the world wide web is the responsibility for revising and updating all that information. In cases where there is a department within the University (e.g., Registrar's Office, Graphic Communications) that is responsible for hardcopy publication of information you want to have on-line, please contact that department to make arrangements for on-line publication.
As each University gets started with the Web, there will be situations where people want information to be on-line that the responsible party is not yet prepared to place on-line. When that happens, it is usually a good idea to contact the people responsible for the University's home page, so that they can coordinate the various projects that are in progress.
By working with the party responsible for the information that you want to have linked with yours, you can ensure that the proper tags are inserted in the on-line version of their documents, too.
Using lists for a set of links, rather than embedding those links in a paragraph, has the advantage that Lynx users will be encouraged to use the down arrow key to get from one item to the next, the correct method. If the items are embedded in a paragraph, a Lynx user might type, for example, the right arrow, which will take them into the current link, rather than moving over to the next link. The list format therefore helps to avoid frustrating your reader!
Feel free to put break, paragraph, or horizontal rule separators between list items to force extra white space. Unlike with paper publications, it does not cost anything extra!
When using this approach your readers will appreciate having extra white space, which makes mouse pointing seem less challenging, so use a paragraph break between lines to increase the vertical separation, and on each line use " " (which forces two non-breaking spaces) between each pair of items, in order to increase the horizontal separation between items.
If there are only a few destinations, you can use a separate graphic for each, whose ALT strings will provide the identification for Lynx users. If there are more than a half-dozen destinations, then use an imagemap with a single graphic file, and create a separate text.htm file for Lynx users unless there are also text based links to those destinations in the body of your page.
In each of these, the link from the shortcut text or graphic is directly to the location of interest.
With either form of shortcuts, a single "larger" graphic is appropriate on the top part of the first screenful of a home page. Such a graphic should be at most 520 pixels wide and at most 200 pixels high, preferably between 450 and 470 wide and approximately 125 high. The limitation on width is in order to be able to see the entire graphic on the default window width of Macintosh Netscape, and for the entire graphic to be printed with the page. The limitation on height is to ensure that as many as possible of the shortcut links will be visible on the first screen of the page, even by people using the old standard VGA (640 x 480-pixel) display. Example graphics include:
This banner graphic and the shortcut button array graphic should be designed together. They do not have to be of the same width, but the aesthetics of the combination should be considered, rather than creating them independently.
Because they ignore the various Table tags, non-table-aware browsers are only likely to do something readable with a single-row table, especially if the first item within each cell is tagged as a header. For partially table-aware browsers, such as the latest version of Lynx, you should experiment and see how it works.
A tabular presentation can also be achieved by using pre-formatted text. Remember to keep each line to at most 80 displayed characters (not including any embedded tags), so that it will be displayable in Lynx.
Beware using STRONG format or HEADERS within pre-formatted text: most browsers display strong formatted text and headers by using bold-face, but each bold-face character is wider than the corresponding plain character, destroying the intended column alignment.
Beware setting background colors for individual table cells. Version 2 of Netscape ignores table cell background colors, but does obey BODY attributes for text and link colors, as well as FONT color tags, including those within cells. It is therefore quite easy to create a table that looks very nice in later versions of Netscape, but in which the text is impossible to read using Netscape Version 2, because the text and background are identical colors.
Beware using table structures to attempt to control the placement of items on the screen. Such pages are always fragile; they will be broken by having the window set to different dimensions than anticipated.
There are situations where animated images are the most appropriate method to convey information (for example, to show the flow of materials in a chemical engineering process). Animated images, where they will work, are less burdensome than a QuickTime movie clip.
It detracts from a Web page, however, to use an animated image where no animation is necessary.
Be aware, also, that faster machines are likely to display the animation sequence so suddenly that it is just a blur anyway, and loses all postive impact.
When your reader prints a page containing an animated image, only one of the sequence of images will be printed, essentially at random, so your page is likely to look lame when printed.
Horizontal rules aren't pretty, but they are robust, and robust is better than fragile.
Lynx is important for several reasons, including:
For graphical browsers, this viewing should include consideration of at least the following:
On the web, unlike hardcopy publishing, type faces are controlled by the browser. Lynx uses fixed-pitch fonts for all text, because Lynx works with displays of 24 rows of 80 characters each. Netscape usually uses two type faces, a proportional-spaced font (usually Times) and a fixed-pitch font (usually Courier). Browsers that don't know about the font or bold tags will ignore them, and the text "marked" with those tags will simply blend in with the surrounding text, instead of being emphasized.
The choice of a white background is especially appropriate for a web page that is to be used as a slide show for a presentation, because it increases contrast, and therefore enhances the readability of the projected display. Beware specifying colors by name (e.g., "darkgreen") instead of by RGB color value (e.g., #006000). Many older graphical browsers are still in use that do not understand the color names.
Typewriter format will look just the same as the surrounding text when viewed with Lynx or other text-based browsers, so do not use it for emphasis.
In scholarly work, it is common to format bibliographic citations using italics for certain parts of the text (e.g., the title of a book or journal). It is probably better to conform to that standard style, and be hard to read, than to appear illiterate.
For positive values of n, you should instead use either strong format or header tags (see the next item). Negative values of n are a major readability problem, because most people adjust their browser to display text with a default size that is as small as they can comfortably read on screen, in order to provide the maximum amount of interesting information on the screen at any one time. Even going down one step in font size will make it much harder for many people to read.
Do not use header tags to emphasize a whole paragraph, use strong format if you must, but it is even better to use some other technique to make a whole paragraph special. (This paragraph, for example, is preceded and followed by horizontal rules, and those horizontal rules are included, along with the paragraph, in a blockquote section.) See also the next point.
Sometimes a complete short sentence in the middle of a paragraph will look OK in strong format.
Other guidelines are also available on-line.
Including the in-line thumbnail logo inside the link causes the image's ALT string, if any, to be part of the link text when viewed from Lynx. This also has the result that in Lynx a single down-arrow keystroke will move past that link, instead of requiring two keystrokes. Be sure to include a space character or non-breaking space (" ") between the image and the rest of the link text.
Netscape displays a characteristic (blue or magenta) border around an in-line graphic, when the graphic is part of a link. The border is continuous with the underlining of the text part of the link. Clicking on the icon functions identically to clicking on the highlighted text of the link, and with many graphical browsers there is no "dead" space between them where clicking accomplishes nothing.
There are three ways this might happen:
The simplest way to avoid this problem is to be sure to always use all lowercase letters in URLs for resources on such servers, even though any combination of case will work to get to the pages.
The simplest way to avoid this problem is to be sure to always write the URL out in full, including the filename. This is also required in order to be able to test the link from your hard disk, if it refers to one of your own pages.
The complete URL (with the correct IP address if it is an absolute URL), including the full path and filename, should be used both in anchor tags and in imagemap data files.
Dick Piccard revised this file (http://ouvaxa.cats.ohiou.edu/~piccard/oacrao97/fragile.htm) on November 13, 1997.
Please E-Mail comments or suggestions to "piccard@ohiou.edu".