More Real World Cross-Browser HTML Development

By Joel Anderson and Chris Kunicki

In the May 2000 issue, we discussed practical suggestions to deal with common, yet subtle cross-browser HTML development issues. These issues often affect the design and resulting appearance of Web pages. It was our simple goal to share a few suggestions we thought other designers and developers might find interesting. To our surprise, many readers were struggling with the issues we mentioned.

The fact is: You're not alone if you find yourself cursing a browser because it refuses to render your HTML the way it's documented. A few readers shared funny names they've coined; for example, one team referred to a browser as "the devil's window."

Many readers asked about where they could find more suggestions like the ones presented in the original article, whether online or in print. Our HTML developer peers from around the world shared a number of great workarounds and tips with us; so many, in fact, that we felt a second article was warranted to share and refine these ideas, and continue this collaborative effort.

Inconsistent Input Field Sizes

Many readers wrote in to complain about input fields. The sizes of form input fields are generally controlled by the SIZE attribute. However, Internet Explorer (IE) and Netscape interpret the meaning of this attribute's value differently. Listing 1 shows the code for a simple form with an input field. Even though the field has an attribute of SIZE="75", it is displayed so that it nearly fills the width of a 640 x 480 pixel page in Netscape. In IE, it only fills about 85 percent of the page, as shown in Figure 1.

This happens because Netscape renders input fields with the browser's default fixed-width font; IE, on the other hand, renders it with the browser's current page font.

The traditional solution is to select a value smaller than the size that is actually desired. This will account for Netscape's exaggerated interpretation of the SIZE attribute, but the input field will still appear differently in the two browsers.

Fortunately, there is a better way to deal with the form field size issue. The answer relies on Cascading Style Sheets (CSS). With CSS you can specify a monospace font for your input boxes, resulting in field sizes that are nearly the same in both IE and Netscape. The second HTML code segment in Listing 1 demonstrates the solution. First define a style that uses a monospace font as the font family. Then, apply that style to your input boxes.

The disadvantage to this solution is that many older browsers don't support CSS. If you have the luxury of designing only for the new generation of browsers, then this solution could be your new best friend.

Extra Space Around Images in a Table

Neatly coded HTML has several advantages, such as ease of readability. We've been taught that the browser ignores white space in your code, and that it doesn't care if your tags are all bunched up on the same line, or whether each <TR> tag appears cleanly on its own line, as in Listing 2. (Humans, of course, prefer the latter because it's easier to read and debug.) However, there are a few places where the browser will render pages differently based on where you use extra line breaks in your code. For instance, if you place an image inside a table cell, a carriage return in the wrong place can create unwanted space around the image.

Figure 2 shows how two images located in separate table cells can be rendered differently depending on how they're coded in the underlying HTML. In both the IE and Netscape examples, the box on the left is an image surrounded by <TD> and </TD> tags on the same line as the <IMG> tag. The red background of the table cell shows only at the top and bottom of the cell. The box on the right is an image whose <IMG> tag is followed by a carriage return before the closing </TD> tag. Notice how this causes the image to shift inside the cell, uncovering various amounts of green background color.

Listing 2 shows the code for this example in more detail. The seemingly innocent line break after the <IMG> tag and before the </TD> tag will create extra space around the image. Not surprisingly, the extra space is different in Netscape and IE. Both browsers will put a few pixels of extra space below the image, but Netscape will also put extra space to the right of the image.

To avoid the extra space and achieve consistent results regardless of browser, always place a closing tag (</TD>) on the same line as the <IMG> tag, as we've done in the second segment of Listing 2.

The principle of using clean syntax also applies to specifying style; see "Define with Caution."

Tiled Background Images

Applying the BACKGROUND attribute to a <TABLE> tag lets you place an image behind the contents of a table. This technique can be used to create some interesting layering effects. However, it's important to be aware of subtle differences in the ways Netscape and IE handle table background images.

Netscape will tile the background image within each cell, which means that it displays the background image in each cell and repeats that image as many times as necessary to fill the entire background of the cell. It repeats this method for each additional cell in the table. Unless your cells are sized to an exact multiple of the image size, Netscape will pad the table cells with fragments of the image. The result is a mosaic of complete and partial images.

IE, on the other hand, lets the background image span multiple cells. It will still tile the image if necessary to fill the table, but because the image will not be cropped at the edge of every cell, we need not be concerned with the size of our table cells.

An additional inconsistency is introduced if we use a CELLSPACING value greater than zero in the table. Netscape will render additional copies of the background image in the newly formed spaces between cells. In IE, this is not an issue because of the way the tiling spans multiple cells.

Because of these differences, table background images are not very practical unless you know which browser your audience will use. There is, however, one case in which a table background image | behaves consistently between the browsers: when the table contains a single row and a single cell, as outlined in Example 1.

Stretched Horizontal Lines

Sometimes the <HR> tag just isn't enough. To create a beveled line that spans an entire page, many developers will use a small GIF image with the WIDTH attribute set to 100%. The image is small, generally a single pixel wide and two pixels tall. If the top pixel is darker than the bottom, the resulting stretched image will form a nice, 3D bevel that shrinks or expands according to the maximum size of the browser window.

Unfortunately, the WIDTH="100%" trick works only in Internet Explorer. Netscape doesn't know how to process the relative values, like percentages, that it finds in the WIDTH portion of IMG tags.

But what if you really do need a beveled line that stretches across a page? Here's a crude solution: Throw away the two-tone GIF file, but remember the color codes. Listing 3 shows you how to use the colors within tables to create an effect that looks like a stretched, beveled line.

Inside the <TABLE>, create two <TR> rows. And inside each row, create a single <TD> cell. Set the BGCOLOR of the cell in the first row to the color of the dark pixel from the original GIF image. Set the BGCOLOR of the cell in the second row to the color of the light pixel. Then, set the WIDTH of the two cells to 100%.

We're not quite done yet. Because Netscape won't fill an empty table cell with a background color, we need to put something inside the cells. A nonbreaking space ( ) is too big, but we can always use a transparent single-pixel GIF image. Be sure to put the <IMG> tag inside each cell. Set the WIDTH and HEIGHT of the <IMG> tags to 1. The image doesn't need to be any bigger than one pixel because it won't be visible on the rendered page. It's just acting as a place holder so that Netscape will fill the cell with a background color.

This solution does require the browser to load two images instead of one—there are two <IMG> tags now, whereas there was previously only one. Ordinarily, we'd recommend keeping the number of spacer GIFs to a minimum, but the 3D effect can be interesting and most browsers will cache the image, so it shouldn't impact performance too significantly.

Trademarks and Soft Hyphens

It is not uncommon in the competitive world of the Internet to want to identify and protect valuable intellectual assets. There are a number of special characters supported by HTML to present copyrights, registered trademarks, and trademarks. For example, you may want to use the "circled-c" copyright symbol. Fortunately, HTML supports Character Entity References that let us provide a named entity reference or a numeric entity reference. Both © and © represent the copyright symbol in HTML. Most people usually use © because it's easier to remember.

Some people have taken to using ™ when they want to display a trademark symbol (the superscripted TM). This is fine in IE, but unfortunately Netscape doesn't recognize ™ as a special character and will literally display ™ in the middle of your text.

The solution to this issue is to use the numeric entity reference ™. It may make your code less readable to other developers, but both browsers will correctly produce a superscripted TM. Figure 3 shows the different ways to display a trademark symbol.

Another interesting character that acts differently in the two browsers is the soft hyphen, represented by ­. When placed between syllables in your text, the soft hyphen is supposed to improve word wrapping. If you look at the code in Listing 4 you will notice ­ used throughout the text.

Contrast the IE and Netscape displays in Figure 4. As you can see, Netscape will display each occurrence of ­ as a soft hyphen. This breaks up your text and is probably not what you want. IE for Windows, on the other hand, appropriately wraps words based on the placement of the soft hyphens. IE displays actual hyphens only where the words wrap.

This is great for designers and content creators who want words to break at an exact spot. But, oddly enough, IE 4.5 and 5.0 on the Macintosh platform treat ­ in the same way that Netscape does, displaying each occurrence of ­ as a dash. Apparently the IE for Windows development team took some liberties with the HTML rendering engine. The net result: Avoid using the soft hyphen technique unless you're developing for a controlled-browser environment (which, of course, defeats the purpose of writing HTML that works across browsers for public consumption).

Scripting Differences

Many sites use client-side scripting for form validation, image rollovers, and a number of other tasks. As you probably know, both Netscape and IE have implemented "JavaScript" with minor differences, causing a few problems. The good news is that these differences are minor and it's relatively easy to work around them.

A common technique for dealing with browser script incompatibilities is to use browser detection. A script can examine the appName and appVersion properties of the navigator object (as with navigator.appName and navigator.appVersion) and decide which branch of code the browser should follow. This form of browser detection requires that we code an appropriate branch for each browser type and version. Furthermore, as new browsers are brought to market, we may have to adjust the detection code to accommodate new inconsistencies.

A better technique is known as object detection. Instead of deciding which browser is being used, we can determine which objects are available via the Document Object Model (DOM), and script accordingly. Listing 5 shows an example of how to use object detection techniques for image rollovers.

These few lines of code let you write browser independent, client-side scripts. The technique provides graceful down-level browser support. If our visitors are still using old browsers that don't support the DOM objects we're scripting for, the if statement will return false. As a result, our DOM-specific code never executes and our visitors will never have to see a JavaScript error.

The other benefit is that our code will continue to function on future browsers. If Netscape suddenly starts supporting objects in the Microsoft DOM, our code will automatically adapt.

IE's Justify Bug

One astute reader alerted us to an interesting and subtle issue for those using CSS. There is a bug with IE's implementation of the justify option for the CSS text-align property. Any block of text formatted like the code in Listing 6 may render with double words. We captured this happening in Figure 5.

As you adjust the width of the browser window, a little bit at a time, you should be able to find a window size that causes some words to appear twice consecutively—once at the end of a line and again at the beginning of the next line. This bug seems to occur only when the combination of justify and italic is used. Text formatted in this way renders fine in Netscape. Even though we don't have a solution to this problem beyond not using this combination of CSS Properties, we think it's good for HTML developers to know about and avoid potential embarrassment.

An Imperfect World

As designers and developers, we are troubled every time we have to spend a few hours tracking down a subtle rendering issue like the ones documented here. But it's refreshing to know that there are often answers to many of these problems and that we can be comforted in knowing that we're not doing anything wrong.

As much as we like to dream about a better future where the various browser vendors work together more closely, or standards like XHTML are universally adopted, for now we choose to focus on the ugly, but real, world. Of course this means we need to communicate with other developers and use that same spirit of good will to help one another. If you find any of these suggestions useful, or better yet, if you have ideas you'd like to share with other developers, please send us your comments.

(Get the source code for this article here.)

---

Joel is a senior Internet developer at Plural. Contact him at andersjt@visi.com. Chris is the CTO of www.hiptrends.com. You can reach him at chris@hiptrends.com.