Handan Selamoglu, Microsoft Corporation
Based on a presentation by Kevin Drew Davis, Blue Marble
November 20, 1996
As today’s Web browsers race to embrace new Hypertext Markup Language (HTML) standards from the World Wide Web Consortium (W3C) and (at times) create their own extensions, it’s often difficult to keep up with the latest details: Which browser supports which HTML tags? How can you create sophisticated sites without alienating a large segment of your audience? As a Web author or designer, what are the tricks involved in making your site “degrade gracefully”—that is, ensuring that your site is usable across browsers? This article provides a checklist of guidelines for Web authors who wish to create content for multiple browsers, including Microsoft® Internet Explorer and Netscape Navigator.
The article is based on the presentation “Making Your Content Viewable on Multiple Platforms,” by Kevin Drew Davis at the Site Builder Conference, October 28-30, 1996, in San Jose, California. Kevin Davis is Director of Interactive Development at Blue Marble (http://www.bluemarble.com/).
Before we dive into specifics, here are some general guidelines to follow when designing your Web pages.
Chart your options. When you author your Web pages, it’s a good idea to start with a chart of features you wish to include on your pages (for example, tables, frames, controls), and map these against the browser support available for each feature. For example, if you’re designing frames, you’ll need to know that Microsoft Internet Explorer 2.1 on the Mac doesn’t support frames, and you’ll need to provide a way for your Mac readers to view the content. Check BrowserWatch (http://browserwatch.iworld.com) for a compilation of browsers and technology support information. For details on HTML support in Internet Explorer 3.0, see "HTML Authoring Features for Internet Explorer 3.0"
Avoid large downloads on your main page. One sure way to alienate your readers is to force them to download a large control or graphic on your home page. If you do decide to include downloads (for example, controls or plug-ins) on your site, specify the system requirements and size of the download and make it optional. It also helps to add a simple script to allow users to cancel out of a lengthy download (see Adding Controls to Your Home Page below).
Remove the resource fork for your images and documents. Resource forks (which store resource and preference information for Apple® Macintosh® files) are Macintosh specific and will take up unnecessary space. Clean up your files by opening them on the PC and selecting “Save As”.
Double- and triple-check your code. When it comes to HTML syntax errors such as missing quotes or end-tags, not all browsers are as forgiving as Microsoft Internet Explorer. For example, if you miss a closing quotation mark in your HREF statement, Internet Explorer will assume it’s there, but Netscape Navigator will ignore the entire link specification. You can avoid a lot of headaches by making sure that your HTML syntax is clean.
Layer client-side and server-side image maps, and offer a text option. If you're using a client-side image map, also include a server-side Common Gateway Interface (CGI) script to accommodate browsers that don’t support image maps. It's also important to add a text option so that readers who browse your site with images turned off can find the basic information.
Use good tools, especially HTML checkers. It's easy to make HTML syntax mistakes (for example, missing delimiters and quotes), even if you're an HTML guru. Avoid headaches by investing in a good HTML editor that will check the syntax of your pages. There are a number of tools out there, for example, SoftQuad's HoTMetaL for the PC and BBEdit for the Macintosh. Choose the one that best fits your needs.
Know your audience. The choices you make, the technologies you use, and the browsers you target should be determined, in large part, by the usage patterns of your target audience. Are your readers consumers? If so, chances are they're also AOL users. Are they techies? Then they're more likely to use Mac and PC browsers. Are they predominantly Mac users? Remember that they won't be able to view Java™ applets, so code accordingly.
Branch for browsers where possible. Instead of coding your HTML to comply with the lowest common denominator (which can be very restricting), redirect your users to pages customized for specific browsers. You can use server-side scripting to check for browsers. If you have an international audience, also consider adding language options. (Keep in mind, though, that maintaining multiple sets of pages can be very resource intensive.)
Use the 216-color "safety" palette. Here's a little-known fact: The 256-color Windows® palette is different from the color palette available on the Mac. Say you're using the 256-color palette to design your graphics and they look great on your system. This is no guarantee that your graphics will display the same on someone else's machine—they might show up with entirely different colors. To prevent this from happening, use the “safety” palette, which works on everything, including old SVGA monitors. You pay a very small price (you lose only a few colors) to ensure that your graphic displays correctly on different platforms.
Always include the ALT parameter in your <IMG> statements. Use the ALT parameter in your <IMG> statement to provide a text placeholder for the image; for example:
<IMG SRC="my_image.gif" ALT="Click here for more info">
ALT tags have two advantages:
Always include WIDTH and HEIGHT specs in your <IMG> statements. Internet Explorer formats the page with text first and adds the graphics later. If you don’t specify the size of your graphic, the browser will have to reformat your page when it downloads the graphic and obtains that information. This results in an annoying screen flicker. Instead, give Internet Explorer enough information in the <IMG> statement so it can format your page correctly on the first try.
Try to provide text-only navigation. Many power users choose to browse the Web with graphics turned off—a perfectly reasonable thing to do if you have a 14.4 connection. Instead of alienating these users, be sure to provide text elements for navigation. Say you have a graphical navigation bar. You can easily duplicate these links with a list of text items at the bottom of your page, or use text and graphics together in your navigation bar.
Choose the appropriate resolution for your readers. If your audience consists of high-end PC users, you're pretty safe designing for an 800x600 screen. If you're targeting a more general audience, stick with 600x480 and keep your pages short—many of your users won't know how to scroll. (Amazing, but true!)
Avoid nested tables. It may be tempting to do wild and crazy things with tables, for example, you may want to use nested tables to create sophisticated page layouts. After all, HTML doesn't give you many choices for positioning images and words on the screen, so you have to be creative with what you get. Either resist the temptation or be very careful in your implementation. Some browsers (for example, Mosaic) don’t handle nested tables gracefully.
Lay out text and images before adding table tags. You can ensure that your table data is complete and in the right order if you finalize the table text before you add the formatting tags. This method may also help you realize that you didn't need a table to present the information after all. Use tables for data, which is what they were meant for, not for layout.
Avoid specifying sizes in <TD> tags. Fonts and sizes may be different on readers’ systems, so specific <TD> size parameters can result in truncated text.
If you use colors, choose them wisely. Many browsers don’t support cell background colors, so if you’re using this feature, be cautious in your choice of colors. For example, white text on a black background will display correctly with Internet Explorer, but will disappear (because it will appear white on white) in Netscape Navigator 2.0. If you're using color in your tables, choose light backgrounds and dark text.
Build from the bottom up. Frames can be frustrating if they’re not implemented correctly. Because frames are complicated, it’s best to add them after your site is functional. This way, it’s easier to check and test the functionality of your pages, and you’ll have a better understanding of whether your use of frames is necessary. Note that most users find framed sites confusing, so design wisely.
Target="_top" is your friend. This target value gets you to full-screen mode no matter how deep you are in your frameset. (It's like a “reset” feature that allows readers to return to the main page.)
Target="_new" can be confusing. This target setting instructs the browser to open a new browser window. However, you don’t have any control over the size and placement of the new window, so this can be confusing to your users. They may not be aware that a new window is open and thus end up with a plethora of browser windows on their desktop.
Be careful, consistent, and original in naming frames. Consistency and originality in your frame names will help you avoid conflicts with other framed sites. For example, let’s say you’ve named your table of contents frame "contents". Perfectly logical, isn't it? Precisely, which is why other sites may be using this frame name as well. You may find your table of contents appearing where you least expect it—in another site’s frame. Your frame names don't have to be elegant—just unique—and you can easily make them so by adding your site name as a prefix.
Cover all your bases. You can support multiple browsers simply by adding complementary HTML tags to your <OBJECT> statements.
Here's your typical <OBJECT> tag for placing an object (in this case, a Shockwave control) on your page:
<OBJECT ID="ShockWave1"
CLASSID="CLSID:166B1BCA-3F9C-11CF-8075-444553540000"
CODEBASE="http://www.macromedia.com/..."
WIDTH=100 HEIGHT=100
>
<PARAM NAME="swURL" VALUE="my_movie.dcr">
</OBJECT>
What's wrong with this? Internet Explorer displays it beautifully, and will download the control if it isn't already on your system. Other browsers, however, do not understand the <OBJECT> tag and will not know what to do with this syntax.
A better approach would be to use:
<OBJECT ID="ShockWave1"
CLASSID="CLSID:166B1BCA-3F9C-11CF-8075-444553540000"
CODEBASE="http://www.macromedia.com/..."
WIDTH=100 HEIGHT=100
>
<PARAM NAME="swURL" VALUE="my_movie.dcr">
<EMBED SRC="my_movie.dcr" ALT="Cool Shockwave Movie"
WIDTH=100 HEIGHT=100>
</EMBED>
</OBJECT>
The <EMBED> tag we've added above allows browsers that don't support <OBJECT> to find and display the Shockwave control.
What about browsers that don't support either tag (for example, Apple browsers)? You can add a <NOEMBED> tag with a replacement for the control (for example, an image that illustrates the control) to play it safe:
<OBJECT ID="ShockWave1"
CLASSID="CLSID:166B1BCA-3F9C-11CF-8075-444553540000"
CODEBASE="http://www.macromedia.com/..."
WIDTH=100 HEIGHT=100
>
<PARAM NAME="swURL" VALUE="my_movie.dcr">
<EMBED SRC="my_movie.dcr" ALT="Cool Shockwave Movie"
WIDTH=100 HEIGHT=100>
</EMBED>
<NOEMBED>
<IMG SRC="my_image.gif" ALT="Cool Shockwave Movie"
WIDTH=100 HEIGHT=100>
</NOEMBED>
</OBJECT>
Now you have a syntax that will work for all browsers.
If you have a Java applet that performs the same functionality as the Shockwave control, here's how you can provide access to it:
<OBJECT ID="ShockWave1"
CLASSID="CLSID:166B1BCA-3F9C-11CF-8075-444553540000"
CODEBASE="http://www.macromedia.com/..."
WIDTH=100 HEIGHT=100
>
<PARAM NAME="swURL" VALUE="my_movie.dcr">
<APPLET CODE="my_applet"
WIDTH=100 HEIGHT=100>
<IMG SRC="my_applet.gif" ALT="Cool Java applet"
WIDTH=100 HEIGHT=100>
</APPLET>
</OBJECT>
Again, the IMG statement provides a static image to be displayed in browsers that support neither objects nor applets.
The Blue Marble site (http://www.bluemarble.com/) provides a good example of this approach: The home page contains an HTML Layout Control for special effects. Mac users see an animated .GIF instead, and virtually everyone who comes to the site sees the essential elements.
Java is not entirely stable on some platforms. Keep this in mind before you add Java code to your pages, and be sure to test your code on various browsers (see Testing Your Pages below).
Scripting is currently available only to Internet Explorer and Netscape Navigator users. For example, the AOL browser does not support MicrosoftVisual Basic® Scripting Edition (VBScript) or JavaScript, so try not to make it mandatory for viewing your site. Make sure that your site functions (at least at some level) without the scripting code.
Declare your scripting language. If you don't specify the scripting language you're using in the <SCRIPT> tag, for example:
<SCRIPT LANGUAGE="VBScript">
...
</SCRIPT>
the browser will assume the default language set for the browser. Since scripting languages use different syntax, you may end up with scripting errors.
Use comment tags. Delimit your script with comment tags:
<SCRIPT LANGUAGE="VBScript">
<!--
...
-->
</SCRIPT>
Otherwise, your script will be displayed as text in browsers that don't support the <SCRIPT> tag, and Netscape Navigator will attempt to read the code as JavaScript, resulting in syntax errors.
If you're adding a large control (let's say, the HTML Layout Control) to your home page for downloading, be sure to give your users the option to cancel out of the download. A simple script that checks the DrawBuffer property of the control will do this for you:
sub window_onload
on error resume next
REM
c.drawbuffer=140000
if (err) then
REM
document.write "<html><body bgcolor=FFFFF><center>
Put HTML here for users who cancel out of downloading
the control
</center></html>
document.close
end if
end sub
Finally, test your Web pages using as many browsers as possible, especially:
Mosaic provides a good "safety" test—if your pages work in Mosaic, they're likely to work in the majority of browsers. Lynx is a text-only browser, so it allows you to ensure that your site works with graphics turned off.
As a Web author or developer, you have no control over the browsers your readers are using. Following the tips we've provided in this article will help you ensure that your Web site displays and functions correctly (or, at least, "degrades gracefully") on most browser platforms. The four rules of thumb: Know your audience, know your browsers, use good tools, and create great sites!