Q. & A. - Looking Good
Skip other details (including permanent urls, DOI, citation information): This work is protected by copyright and may be linked to without seeking permission. Permission must be received for subsequent distribution in print or electronically. Please contact [email protected] for more information.
For more information, read Michigan Publishing's access and usage policy.
On the eve of the year 2000, many people will be reflecting on the incredible advances of the last century, particularly the wonders of technology. Many Web publishers, however, will be cussing that technology, scratching their heads and wondering why it's still impossible to create pages that look good — or even similar — to all Web visitors.
The great promise of the Web and its underlying technology — Hypertext Markup Language — was that such uniformity was guaranteed, no matter what type of computer a viewer was using. The reality is far from that promise, though. It's still possible to put a great deal of time into page design that looks fine on one browser on a specific platform but looks terrible on others. In this column, we'll look at some of the problems standing in the way of uniform presentation of Web pages, and solutions to those problems.
Battling Browsers
A few years back, it was common to hear about "The Browser Wars." Netscape's Navigator and Microsoft's Internet Explorer were in a constant race to add new features, and for a while major updates appeared every few months. New contenders frequently entered the fray to try to unseat the two titans.
That may seem like a long time ago, and the wars may seem like just a historical footnote in the development of the Web. In some ways, that's accurate: About 90 percent of Web surfers today use either Navigator or Internet Explorer. But unfortunately for Web publishers, that's not the whole story. A visit to BrowserWatch makes that immediately clear. The site lists twenty-four varieties of Internet Explorer and twenty-seven varieties of Navigator. [1] As Jakob Nielsen recently noted, Web surfers are hanging on to older versions of browsers for long periods: sites will have to support users with version 3 browsers until early 2001 ... version 4 will have to be supported until late 2003. [2]
All those variations add up to a wide range of problems for publishers. For one thing, they all support various (and different) combinations of features, including several important ones:
- Java and JavaScript
- frames
- style sheets
- dynamic HTML (DHTML)
- table color [3]
In addition to the two major browsers and their versions, more than a hundred different versions of other browsers are still floating around. [4] While most of them are rarely used, some need to be taken seriously. For instance, about a half million people use WebTV for their Web surfing, a number that's bound to increase now that Microsoft owns the company. [5] And WebTV has its own set of features and problems.
Obviously, it's going to take some doing to make sure that most of your visitors get approximately the same pages in terms of appearance and functionality. Perhaps the best advice is the simplest: Stick to the features supported by most browsers when creating pages, and resist the urge to load them with advanced features. After all, having the best content is far more important than having the latest technology.
More Land Mines
Even if you can tiptoe around the features issue, there are more land mines ahead. Two of the more troublesome are offset and text size.
Offset refers to the padding that browsers stick between the window and contents. Typically, there is about a 10th of an inch of horizontal and vertical offset. For many publishers, this isn't a consideration. But that offset can trash the look of graphically rich pages. The bad news is that the offsets vary by browser and platform; the good news is that it's easy to get rid of — but only for viewers using recent versions of Navigator and Internet Explorer. To get rid of the offset, simply add the following attributes to the BODY tag: [6]
<BODY MARGINWIDTH=0 LEFTMARGIN=0 MARGINHEIGHT=0 TOPMARGIN=0>
The MARGINWIDTH=0 and MARGINHEIGHT=0 are Netscape specific. LEFTMARGIN=0 and TOPMARGIN=0 rid you of the margins in Internet Explorer. The former duo won't work in Internet Explorer; the latter duo won't work in Netscape. In other words, you must specify four parameters where two would suffice if there were conformity with W3C standards.
Text size isn't a function of browser variations but of the platforms that surfers use — Mac or Windows PCs. Again, for a page full of text, this isn't a major issue. But the differences in how typefaces appear from one platform to the other can transform a swan into an ugly duckling. For instance, at standard font size (i.e., <FONT SIZE=4>), Arial is rendered at 14 points on a Macintosh — and a whopping 18 points on a Windows PC. At <FONT SIZE=7>, the difference is staggering: 48 points on Windows PCs vs. 26 on Macs. The effect is somewhat predictable: Windows PCs usually render type larger at a given font size than Macs do. But that's not always the case. For instance, with <FONT SIZE=1>, there is no difference; both platforms produce 10-point type. Additionally, the two platforms produce significant differences in tracking (vertical spacing between letters) and leading (horizontal spacing between lines).[7] The problem is so bad that some publishers have gone as far as banning page designers from using Macs, because most Web surfers use Windows PCs.
Short of such a ban, designers can deal with this problem in one of two ways. The first is to design using only font sizes that are comparable across platforms. (You can find an invaluable comparison chart at Webmonkey [formerly http://www.hotwired.com/webmonkey/templates/print_template.htmlt?meta=/webmonkey/99/41/index3a_meta.html].) If it's not possible to stick to sizes that look similar on different platforms, you might want to create separate pages for viewers using Windows PCs and Macs; a simple browser-detect JavaScript can determine what platform a user has and deliver the appropriate page. [8]
Two More Things
Yet another factor is the canvas size, the amount of space available within the browser window. This one scores high on the complexity scale: It is a factor of both browser and platform as well as of monitor resolution. (Just to complicate matters further, the canvas size also depends on offset.)
Most Web surfers set their monitors to 640 x 480 or 800 x 600 resolution. No one seems sure what percentage use each of them (or even higher resolutions). But even trying to design for just one of those resolutions can be tricky. For instance, at 640 x 480, a Windows PC running Internet Explorer 3.x offers a canvas width of 613 and a height of 276 pixels. In contrast, a Macintosh running Internet Explorer 4.5x at the same screen resolution has a width of 563 and a height of 318 pixels. [9] Again, this is no big deal if your pages contain text and an image or two. But for graphically rich pages, these differences can really mess things up. Fortunately, Steve Mulder and Michael Brandt have taken the time to put together a chart of common canvas sizes along with recommendations for creating widely compatible pages.
The last pesky problem takes us back to that supposed standard itself: HTML. Even if you heed all the cautions above, there will be times when a page looks fine in one browser but looks terrible in another browser or even the same browser on a different computer. That happens because some browsers are remarkably tolerant of bad code while others are notoriously cranky.
To avoid unpleasant surprises, you have to do two things. First, run your documents through a code validator. Some HTML editors — such as HomeSite — include validators (as well as other tools that check links and measure how long a page will take to load). If you don't have access to software that lets you validate your code, you can use an online validator. One popular site, Web Site Garage [formerly http://websitegarage.netscape.com], will check the code on one page at a time; it also checks loading time and suggests ways to make graphics appear and load more quickly. The Web Design Group's online validator allows you to check files that are still on a local PC and have not yet been uploaded to the Web — great for publishers who want to make sure pages are ready to go.
One warning: HTML validators often will tell you your code is bad when it works fine. That's because some tags are supported by Navigator and Internet Explorer, but not directly by HTML. You can weed out the non-issues by taking step 2: View all pages in a number of browsers, on both major platforms if possible. If your pages are built on templates, you need to check only the templates. If things look good, you're ready to roll.
Thom Lieb is an associate professor of journalism and new media at Towson University in Baltimore. Among his courses is Writing for the Web. He is the author of Editing for Clear Communication and has written and edited for magazines, newspapers, newsletters and online publication. He holds a Ph.D. in Public Communication from the University of Maryland at College Park and a master's of science in Magazine Journalism from Syracuse University. You may contact him by e-mail at [email protected].
Notes
1. BrowserWatch, http://browserwatch.internet.com/stats.html.
2. Jakob Nielsen, Stuck With OldBrowsers Until 2003, Alertbox, April 18, 1999, http://www.useit.com/alertbox/990418.html.
3. Browser Chart, Webmonkey, [formerly http://www.hotwired.com/webmonkey/reference/browser_chart/index.html]
4. BrowserWatch.
5. Joshua Allen, Getting Your Site Ready for WebTV, Webmonkey, [formerly http://www.hotwired.com/webmonkey/templates/print_template.htmlt?meta=/webmonkey/98/40/index1a_meta.html].
6. Steve Mulder and Michael Brandt, Sizing Up the Browsers, Webmonkey, http://www.hotwired.com/webmonkey/templates/print_template.htmlt?meta=/webmonkey/99/41/index3a_meta.html.
7. Mulder and Brandt, Sizing Up the Browsers.
8. Thom Lieb, Access Code, Journal of Electronic Publishing, June 1998.
9. Mulder and Brandt, Sizing Up the Browsers.
Links from this article:
BrowserWatch, [formerly http://browserwatch.internet.com/stats.html]
Web Design Group's online validator, http://www.htmlhelp.com/tools/validator/upload.html
Webmonkey Browser Chart, [formerly http://www.hotwired.com/webmonkey/reference/browser_chart/index.html]
Web Site Garage [formerly http://websitegarage.netscape.com/]