As Web designers we've all experienced our Web pages looking good in either Netscape Navigator or Internet Explorer, but then degrading from their intended design when viewed in the other browser. Some of us may have designed or maintain sites that serve different versions of pages to the two main browsers. It's enough to make you want to cry "can't we all just get along?"
While the trend is moving away from the illogical practice of designing separate pages for different browsers, it isn't happening fast enough for many. The W3C -- The World Wide Web Consortium issues Web standards, but so far the browser makers selectively and incompletely implement them. If we ever see Netscape's 5.0 offering, it's supposed to be the first totally standards-compliant browser. Frankly, we'll believe it when we see it. We'll also hope that Microsoft hasn't completely won the browser-wars by the time it's released. At this rate it's hard to tell.
In the meantime, here's some of the nitty-gritty, not-always-pretty details of how the two major browser platforms differ in their implementations of HTML. If you take some time to understand some of the basic differences between Navigator and IE, you can considerably minimize those unhappy experiences when first viewing your designs in the other browser.
Even something as simple as screen size, or the "real estate" that you have to work with as a Web designer, doesn't conform to any standards. Of course there are the issues surrounding how your content looks at different resolutions as well, and this should be taken into account in your testing methods.
Other Browsers, Other Platforms|
It's not that hard to play to the lowest common denominator when it comes to page or screen size, if you're primarily concerned with the two standard desktop computer browsers. But it becomes much messier when you start figuring in other options (Opera, Lynx, AOL, etc.), non-Windows platforms (Mac, Linux, etc), all the potential PDA and non-desktops (WebTV, handhelds, phones, etc.). If you're designing for those environments (and we should all be at least thinking about them), be aware that you will have further constraints on your design space.
Some basic things to keep in mind about your screen size are that there are different "canvas sizes," the actual size of the available workspace; and "page offsets," horizontal and vertical buffers from the edges of the workspace.
Canvas sizes range from 723x438 for the Macintosh version of IE 4.5, to 764x414 for the Windows versions of Navigator above 4.0 (at 800x600 screen resolution obviously). To fit into the smallest possible canvas of any of the major browsers, at 800x600 you should be staying within a 723x390 window.
Page offsets are the number of pixels away from the edge of the browser window your page will start. On all Macintosh platforms horizontal and vertical offsets are 8 pixels, on all Windows platforms the horizontal offset is 10 pixels, except Navigator 4 where it is 8 pixels. Windows vertical offsets are most commonly 15 pixels, except in Navigator 4 where it is 8 pixels and IE 3 where it is 16 pixels.
These measurements are courtesy of a Webmonkey article by Steve Mulder and Michael Brandt examining spatial differences in the major browsers. They also make the important point that the very commonly installed MS Office toolbar will eat up even more of that precious workspace.
TablesTables are one of the oldest and most widely implemented HTML features. Just about any browser (excepting AOL 2.7 and below) will display tables and understand their basic tag structure. Unfortunately, tables are not uniformly supported by IE and Navigator.
For instance, the <TABLE> attribute <BORDERCOLOR> was first supported in IE 3.0, but Netscape didn't start recognizing it until its 4.0 version. And if you have a non-zero <CELLSPACING> attribute in a table with a <BORDERCOLOR>, Netscape will retain the 3-D feel of the table and not color any of the internal lines, whereas IE will change the outside lines to solid borders of the requested color, and color the internal border lines as well.
Navigator has long been criticized for problems rendering nested tables, which are coded in a strictly legal manner. Any use of nested tables needs to be tested carefully in Navigator.
Specifically, Netscape has had problems with tables that omit the optional end </TD> tag. IE handles this legal omission gracefully, but if you're using nested tables and have potential Netscape users, you better make sure you close every <TD> tag. Navigator also has problems with carriage returns directly following table cell data, and if there was a hard return in the HTML file before the ending </TD> tag of a table cell, additional space would be added around the cell. This can play havoc with your design if you're using tables for page layout purposes.
Netscape tends to be pickier than IE when it comes to handling improperly coded HTML as well. For instance, if you have a table that's missing the required end </TABLE> tag, IE will still display the table, but Navigator won't.
Another important aspect of Netscape's table rendering, relating to Cascading Style Sheets (CSS), is that table elements will not inherit formatting instructions from parent elements. So, if you specify text style attributes in a style sheet BODY or DIV section, they will not be used by text within a table cell within that DIV section.
Frames are another staple of Web developers, which are widely supported. You have to go back to the Windows 2.0 version of IE to find a major browser that doesn't support them. Early versions of WebTV did not support frames, but one of the advantages of that technology is the automatic forced-upgrades of the clients, and there shouldn't be any non-frames versions of WebTV in use anymore.
Some differences in the implementations of frames are the differences in how you specify borders and the IE-only <IFRAME> tag for inline frames. To toggle frame borders you need to specify <FRAMEBORDER = 0> or 1 for IE, but Netscape originally used <FRAMEBORDER = Yes> or No (although it currently supports the 0/1 usage as well). To set the thickness of borders within a frameset you need to use the BORDER attribute for Netscape, but the <FRAMESPACING> attribute for IE.
With regards to pre-formatted text, while both browsers support the <PRE> tag, only Netscape supports a <COLS> attribute that specifies the number of columns and a <WRAP> attribute that indicates that the text should be wrapped at that width.
If you're working with legal documents, or multiple revisions, you should know Netscape does not recognize the <INS> and <DEL> tags. IE will recognize these elements, and renders the contents of <DEL> elements as struck-through text and <INS> elements as underlined text (easily confused with hyperlinks).
A good way to try and work around this, and to keep from having to serve separate pages for IE and Navigator, is to define reference variables that will hold the appropriate syntax for whichever browser is being used. In other words, if the user has Netscape, assign the variable the Netscape version of the object, and if the user has IE give it the IE version. Then use your reference variable in the script, rather than the Netscape or IE specific syntax.
Here's an IE gotcha: The browser can't handle mixed-case event handlers when used as an object property, so it is best to use only lowercase event handler names. For example, use "onclick" instead of "onClick."
Another important Navigator quirk suggests it would be best to always use only alphanumeric characters when choosing element names. Reportedly some element names with non-alphanumeric characters can be ignored by 4.0 versions of Navigator.
Some other things to keep in mind while coding. Cascading Style Sheets are not supported in Windows Navigator 3.0, and poorly supported in IE 3.0 (Windows and Macintosh). But looking ahead, it's probably a good idea to use CSS-P for positioning elements, as it's a W3C standard supported by both IE 4.0 and Navigator 4.0. Stop using the Navigator LAYER tag, it won't even be supported by Navigator 5.0, let alone IE.
An important difference in CSS implementations is that Navigator does not support changing CSS attributes of an element after the element has been displayed. Navigator and IE also support different techniques for changing positioning attributes. With Navigator you set and access the attributes directly from the element, but with IE you must do this from each element's style object.
Netscape will act unpredictably if you attempt the technique of using negative numbers for margin values in your style sheets, to create overlaps. Also in Netscape, applying styles to LI elements will result in only the associated bullet getting the desired style, not the following text.
One last Netscape style issue. If your styles use the LINE-HEIGHT property, and have it set in points, you may experience problems printing your pages. If you use ems, pixels, or inches you should avoid this problem.
On the Macintosh side, you should be looking at least at IE 3 and 4 and Navigator 3.0, 4.0, and 4.7. If you want an unpleasant surprise, try looking at your pages in 2.0 versions of the browsers. The Windows version of IE 2.0 doesn't even support frames.
Of course, the difficulty comes in having all these browser versions available for testing with. As you're probably aware you cannot easily install two different versions of IE on a Windows computer. So, this leaves you with either setting up a multi-boot system, or dedicating several systems to just be able to test the Windows IE permutations.
There's no easy way around needing multiple configurations to seriously check your work. If you're low on resources you can try enlisting friends with different systems to help, but this can sometimes end up being more trouble than it's worth.
It can also be a trick just tracking down some of these older browser versions. Here's a link to a repository of older versions of Netscape browsers. IE versions back to 2.0 can be retrieved from Microsoft's main download site.
An important step in your testing procedure should involve running your code through an HTML validator, like Bobby or the W3C HTML Validation Service. These services will check your HTML code for errors, and point out any discrepancies between your code and the HTML standard. Bobby will also highlight compatibility issues with the various browsers and help you make sure your pages are as accessible as possible.
Another platform you should probably not ignore is WebTV, and other emerging set-top devices. WebTV has produced a convenient emulator that can be downloaded from its site, so you can test your pages without having to actually have a WebTV account and box. It offers both Macintosh and PC versions of its WebTV Viewer software for free.
We haven't even discussed any of the other popular desktop browsers like Opera, iCab, or Lynx. Of course it is a good idea to test your pages on these browsers as well. In addition to testing in every browser/OS platform combination you can, you should also be testing your pages at a variety of screen resolutions. Obviously, you have to consider your audience at this point, but you should know there are still people out there browsing at 640x480.
Keep in mind that Mac's screen resolution display type at 72 dpi and PC's display type at 96 dpi. This means type will look bigger on the PC platform, and is one reason to make sure to test cross-platform with regards to operating systems, not just browsers.
For the lowdown on the current state of Web standards, visit both the W3C -- The World Wide Web Consortium, and theWeb Standards Project.
There's a good browser compatibility chart over at Web Review. If you want to know if WebTV supports CSS, or if the Windows version of AOL 3.0 supports animated GIFs, this is the place. They also provide an extensive chart detailing CSS implementations in the current browsers.
For an interesting look at transitioning from proprietary DOMs and markup to W3C Standards, check out this Netscape page. There's lots of information there on what exactly won't be supported by Navigator 5.0, such as the LAYER tags and the SRC attribute of the DIV tag.
Perhaps we can all look forward to a day when we can design our pages to one set of standards, and not get any surprises when we first look at them in that other browser.
Bruce Stewart is a telecommunications consultant and technical writer. His articles have appeared on The Site, Web Review, and ZDNet.