> Web Browser Guide

Common Browser Implementation Issues

By Steve Franklin
Rank: 2

The following chart discusses many of the common activities that need to be performed across a variety of browsers. For each task, the differences between browsers are outlined, and a "safe approach" is suggested as a way to reconcile differences across the browsers.

This list will grow over time, so feel free to request or suggest additions for common cross-browser issues. Feedback and requests are always welcome, and will be promptly answered and addressed.

The cross-browser functions that are addressed in this article are as follows:

Rendered font sizes

Overview

Text displays differently on various configurations, whether it is due to the operating system, monitor resolution, or the browser.

Recommended Solution

Try to avoid specifying font sizes in pixels (px) or you exclude individuals who like to scale up the font sizes, and you run into some quirks (particularly with Netscape). One solution is to deploy style sheets that are tailored to the specific browser. You can either build the styles dynamically using JavaScript and a sniffer script, or you can use server-side scripts to deploy the correct style sheet. Realize that browsers let you configure the dpi interpretation, so hard-coding style sheets to browsers can be a real problem. Instead, you should design your sites to flexibly accommodate different font interpretations so that your site looks acceptable under different dpi and scaling configurations.

Background audio files

Overview

Playing background audio is not done the same way in all browsers. If you want to stream MIDI or WAV files, you will have to take different steps depending on the browsers you want to support.

Recommended Solution

First consider whether you want to use background sounds. I have yet to see a good use for it and it can be a very distracting feature. However, if you need the feature, try something like the following (more info in the alt.html FAQ:

  <embed src="file.wav" autostart="true" hidden="true" loop="true">
  <noembed>
    <bgsound src="file.wav" loop="-1">
  </noembed>

You can also accomplish the same functionality with JavaScript after detecting the browser. Different client configurations may not be able to handle the audio format if they do not have a suitable helper application or plug-in that can handle the format.

DOM navigation

Overview

There has been some disagreement in the past regarding the DOM structure and specification. This is being sorted out thanks to standardization by the W3C, but we still see some differences in the way that elements can be located and navigated using the DOM API.

Recommended Solution

Read Effective Cross-Browser Development for some ideas. Now that IE5 and NS6 are converging on a relatively consistent DOM implementation, I would suggest that you focus on correct implementation of the W3C spec, then add tweaking to support non-compliant browsers as necessary and identified by your testing results.

Displaying XML

Overview

XML is an early technology for displaying information in the browsers. Consequently, we run into a problem we've seen before where the major browsers are handling things differently. I'm not convinced that XML is viable for client-rendered display in a cross-browser environment just yet. However, if you are moving in this direction, the following outlines the high-level differences that you should consider.

Recommended Solution

Unless you have significant control over the configurations of the client browsers that you will be dealing with, server-side transformations will be a much more predictable and tailorable way to bring data to the client.

Event handling

Overview

The two major issues to consider with events are a) accessing event information and b) knowing which events are supported for the various DOM elements. The major discrepancies exist between Microsoft and Netscape. In some cases you can avoid the problem through using a subset of features, but in other cases you will simply have to code in support for multiple browsers.

Recommended Solution

Try to avoid event code that is critical to your site and only works in version 5+ browsers. Embellishments to your site can be handled through event code without impacting older browsers. Consider passing the event.target (see setupEventObject) to event.srcElement combined with a handleEvent call to create cross-browser event handling code for explicit event triggers.

Document manipulation at run-time

Overview

There are times when you want to provide some dynamic behavior and display in your documents. Unfortunately, many of the browsers do not support DOM manipulation in the same way.

Recommended Solution

I would suggest that you start writing to the W3C DOM spec as much as possible. Features like innerHtml may disappear much the way that <layer> has vanished from Netscape 6. Test functions and objects before you use them to create robust code. Also, realize that many advanced CSS-P and CSS-2 capabilities are not well supported, so be cautious of using them until the browsers mature further.

Positioning content on the page

Overview

Positioning content on the page is a huge topic that involves CSS-P, layers/divs/iframes, and a discussion of CSS-1/CSS-2 support in the browsers. Although that is outside of the scope of this small section, I will quickly recap iframe, div, visibility, stacking and positioning capabilities of the browsers.

Recommended Solution

If you are going to support Netscape 4, you can expect to use a greatly reduced subset of DHTML features. Furthermore, you will probably end up writing three versions of some of your code to handle NS6, IE5.x, and NS4. If you don't need to work with NS4, then your job is much easier and you will be able to get by (in many cases) with one set of code with some small branches to handle browser differences.

The most important thing you can do with content positioning is to test the results on all browsers. Particularly with advanced features, if you do not test, you may not realize that the results simply are unreadable to some of your viewers. Simple mistakes like iframes for NS4.x and poor positioning of layers/divs can only be caught through proper testing of the page.

Passing BODY styles to elements

Overview

Many browsers do not allow child elements to inherit styles as you might expect. The most common mistake is to set styles in the body that you expect to be inherited by all children (tables, cells, headings, etc). The main reason for this problem is not a bug in the code, so much as a quirky decision on the part of the browser vendors to hard-code some user style sheet information in the browser. This means that <td> elements (for example) have pre-defined styles that over-ride those of the body styles. There are some steps you can take to ensure that look-and-feel styles such as font-size and family are propagated throughout your document.

Recommended Solution

Set your body style up at the top of your style sheet, and include other elements for which you want the styles to apply. There is little risk in putting too many elements in, as you can over-ride them in subsequent declarations. Something like body,select,td,th,... { ... } will help you to keep look-and-feel consistent across a broader range of browsers.

Mouse-overs

Overview

Mouse-over effects are found on a number of sites. Unfortunately, partial support for CSS means that some effects are not properly supported.

Recommended Solution

Image-driven mouseovers consume more bandwidth but are more reliable across a broad array of browsers. If you use CSS and the a:hover property, your pages load more quickly but NS4.x will be excluded. For maintainability and bandwidth reasons, I prefer the a:hover approach. The major browsers support the onMouse* events but you will not be able to get the cheap a:hover effect to work on NS4.x.

Padding around elements

Overview

Recommended Solution

Be aware of differences by using reference sites such as WebReview's Master Compatibility Chart, an IE5/NS4.x Comparison, CSS Bugs or the CSS Browser Support resource. Some small bugs have been identified with all browsers above, but are outside of the scope of this quick discussion. If you are running into a specific problem, use a resource such as DejaNews to look for answers.

Text Backgrounds Without Tables

Overview

Frequently you will want to highlight blocks of text, and it would be nice to be able to avoid using tables every time. You can use inline styles or place style directives in the head of your document. Unfortunately, these will be interpreted differently by the 4.x generation browsers.

Recommended Solution

This is yet another area of CSS where NS4.x will constrain you. If you choose to go with a CSS-driven background approach, your text will look quite bad under Netscape unless it all fits on one line. This, and a number of other common CSS problems can be found in detail at the following site: Browser Comparisons.

Using ActiveX controls

Overview

ActiveX controls are a Microsoft technology for creating reusable components that can be embedded within container applications. Given that they represent Microsoft-proprietary technology, they are only supported in a subset of the browsers.

Recommended Solution

ActiveX technology greatly reduces the size of the audience that you can reach. Unless you can control the browser audience via a corporate Intranet or something similar, you should probably look for a more open solution. ActiveX is a powerful technology, and can lead to very dangerous bugs, inaccessible functionality on your site, security breaches and more.

Client-side scripting

Overview

Wondering what to use amongst Microsoft's JScript, Netscape's JavaScript, standardized ECMAscript, and Microsoft's VBScript? It is generally clear to work with the most standard specification, now being ECMAscript. Here is a quick recap on browser support for scripting languages.

Recommended Solution

Work with core JavaScript capabilities, avoiding any scripting technologies that are not broadly accepted (such as VBScript). Be sure to test and code properly to ensure your JavaScript is cross- platform.

Accessing server-side data

Overview

In some cases, you need to be able to access server data from a database or other similar source. There are a number of ways to do this that are briefly summarized in the following chart.

Recommended Solution

I suggest staying away from proprietary technologies such as ActiveX, even if you are developing for an Intranet. Technologies and needs change, so an open architecture generally wins out in the long run. Try to do your data access on your middle or server tier, leaving the browser to view generated data. That data can be HTML or XML streamed to the client, simplifying compatibility issues (although XML is still quite young).

Whitespace and line breaks in tables

Overview

When laying out content using tables, you may sometimes find that unexpected spaces and gaps occur in your content. Although this can often be attributed to coding errors, there are a few browser-specific quirks that you should know about.

Recommended Solution

Some unexpected white space issues can be addressed by tight packing elements, i.e. <td><img ...></td>. You can move the opening and closing tags of a form element outside of the scope of the table to remove the whitespace from the table. You should be wary of using CSS to format display of tables and table contents, particularly if you plan to support NS4.x.

Web Browser Guide Home | Compatibility Chart | Browser Leaders

Feedback and requests are always welcome, and will be promptly answered and addressed.