Those Cross-Browser Blues: How To Develop Web Sites For Both Internet Explorer And FirefoxThose Cross-Browser Blues: How To Develop Web Sites For Both Internet Explorer And Firefox

It's no surprise that most of the cross-browser issues out there center on Microsoft's Internet Explorer and the Mozilla browser family -- mainly Firefox.

Love it or hate it -- and let's face it, most of us probably either hate it or manifest mere tolerance for it -- Internet Explorer is here to stay, the way Windows itself is probably here to stay. According to the most recent W3Schools report, IE in all its incarnations commands about 58% of the browser usage pie, down from its high of 90% or more, but definitely still large enough to matter.

Then there's the question of which version of IE. IE 6 is still the most widely used version of IE (37%), but IE 7 is gaining fast -- up from 13% at the start of 2007 to nearly 20% of the total. For developers, IE 7 can't catch on fast enough, since it fixes many things that have long been broken in IE 6.

But the introduction of IE 7 is still no cure-all. There are many IE issues that remain outstanding; getting the majority of existing IE users to work with IE 7 (or later) is a slow process; and existing Web sites that are dependent on an IE-specific technology, like ActiveX controls (about which I'll have more to say later), may have trouble switching away to something more browser-neutral.

Against all of this, the Mozilla browser family -- first Netscape, now Firefox -- has made serious inroads. Netscape was the first major Web browser on the PC (aside from NCSA Mosaic, of course), but over time it stagnated and lost out to IE's ascendancy. In only a couple of years, Firefox has turned that situation around and carved out a significant niche across multiple platforms -- 34.5% and climbing, according to the aforementioned report. That said, as Firefox caught on it became clear that many existing sites had been written to favor IE's interpretations of things and didn't render correctly in Firefox.

This situation doesn't seem to be quite as dire as when, say, Firefox was still in its 1.x incarnation. Most broadly trafficked sites today do render properly in both browsers, with only relatively minor variations between them. But Web designers still have to accommodate both IE and Firefox as elegantly as possible -- and to accommodate the smattering of other browsers that have grown in popularity as well: Opera, Safari, and Konqueror, among others.

Incidentally, while Opera doesn't command a very large stake of the browser market, it has a fiercely devoted following. It hews most closely to the Mozilla way of doing things as well, so coding for the most broadly accepted set of Web standards out there will work best for Opera, too.

In the following pages, I look at six major issues that developers should keep in mind when trying to create sites that work properly across all browsers, and provide some possible solutions as well:

Keep in mind that (as we all know) there are so many factors operating when you develop a Web site that not every solution may work for every situation. Also, these categories aren't all-inclusive or closed-ended; something that might be in one category may also lapse slightly into another, or there may be other things I haven't explicitly mentioned that could be dropped into any of them.

1

Quirky Implementations Of Layout Functions

This is the most common place where people run into issues. They create something in one browser, and then find that the way it's rendered in another simply isn't the same because there are different unspoken assumptions at work about how the standard is to be implemented.

Solution:

The first thing to do is find out specifically what's not implementing correctly. If you're looking at a page in IE and text is not flowing correctly or behaving as it's expected to within a box, such as a DIV or SPAN, there's a chance you may be dealing with IE's quirky box model, which handles boxes a little differently from the Mozilla method. There's also a key difference in the way IE and Firefox handle an overflowing box, and IE's odd handling of non-enclosed floats (another box-related issue) is something that still persists with IE 7. The pages I've linked to here dissect the problems in detail and demonstrate a couple of workarounds.

A great many examples of these kinds of deviations can be seen on the QuirksMode site, but it has not been updated recently -- the compatibility grids don't mention IE 7 at all. But you can run live tests against many different HTML, CSS, and JavaScript standards and functions, and see how they behave (or don't behave) in any given browser. There's also a detailed discussion of this sort of thing (from the POV of a Firefox-friendly designer) on the Computer Gripes site. He goes into some detail about specific sites that have caused trouble for Firefox, and describes specific behaviors that may vary (such as horizontal rules created with the HR tag).

2

Proprietary IE-Only HTML Tags

IE's implementation of Web standards includes a whole slew of ad hoc additions to the HTML tag library that don't show up elsewhere. Most of these seem to have been on the wane, but every now and then you run across a site where they still haven't been eliminated.

Solution:

The only viable long-term solution is to move away from proprietary tags, since the few that are really worth using often implement functionality that can be done in a proper cross-browser fashion anyway. Those that aren't cross-browser are usually frivolities.

A simple example: The bgproperties attribute for the body tag allowed you to keep a background image on a page stationary while someone scrolls through the page. This particular method doesn't work in other browsers other than IE, but there is a CSS style attribute -- background: fixed -- that accomplishes the same thing on both IE and Mozilla.

Another proprietary tag I've seen used in IE, but not widely (thank goodness), and that can and should be done away with, is the CSS font / image filter system. This employs the filter: statement in a CSS style declaration to add various kinds of post-processing to images and fonts directly on a Web page. There are some examples on David J. Hark's Web site; view this page in IE and then in Firefox to see the differences. This is the sort of thing that can be dropped into the same trash can as the blink tag, if only in the name of good taste.

3

JavaScript And Automation

"Fussy" is the nicest word I have for the way JavaScript can be implemented across platforms. What works fine in one place will simply not work at all in another, or won't work as intended. While there's a common pool of commands that is shared by almost every browser's implementation of JavaScript, there are a few that simply don't exist in one browser or the other.

IE, for instance, doesn't implement the JavaScript function getComputedStyle() or the cssRules[] array, while Firefox doesn't implement the handy innerText function. And up until fairly recently (version 9.2 or so), Opera didn't allow frames to be resized via JavaScript. A small omission, sure, but it drove me up one wall and down another, since I was using a JavaScript-resized frame to accomplish a very specific effect that I had a hard time doing another way. (I eventually found another way to do it, but only after the Opera behavior already had been fixed.)

In the same vein, browsers have different ways of reporting back the size of a given window, which can play havoc with window manipulations. In IE, a window's measurements include the "chrome" (scrollbars, menuing elements, status bar, etc.), but in Mozilla, the window's measurements don't include any of that and just run from one inner edge of the window to the other. This makes it slightly harder to create, for instance, a JavaScript window resize that operates reliably across both browsers without handling each browser as a separate case. (Here's a page that talks about the ways different browsers interpret JavaScript window size functions.)

Solution:

Three basic solutions present themselves here:

A. Drop back to a common base of JavaScript for all browser projects. This may only be viable if you have the time and effort to rework all the existing JS code from scratch, as it may be a fairly major undertaking. This means insuring that no future code uses JS that isn't supported on the majority of platforms as well. On the plus side, it means you only have one branch of the code to deal with. Sometimes you can implement individual functions that you need by using "spot cheats," like Scot Hanselman's way to implement the innerText function in Firefox.

B. Use browser detection and browser-specific code. This approach requires that you maintain at least two separate branches of code (IE vs. everything else, essentially), so it's that much more work. One way to implement these kinds of changes in CSS itself without using browser-detection per se is to use conditional style sheets, which apply patches to CSS styles that work for IE but not FF (or vice versa).

C. Use cross-browser libraries. If you want to write JavaScript that works cross-browser every time, one way to do that is to use someone else's JavaScript function library that's been designed to do that kind of work for you. Consider the GNU LGPL-licensed Cross-Browser.com libraries, which package a whole host of useful JS functions in ways that work with pretty much every browser out there. You don't have to include the whole gallery of functions on a given site; you can pick and choose what's needed and keep your include files relatively small. Yootools is another cross-browser function library with some fairly advanced features, including a Window.Size function that helps work around cross-browser window-size issues.

4

ActiveX

This is one part that really drives people crazy. IE-specific ActiveX controls, as opposed to plugins that work in almost all browsers (such as Flash or QuickTime), force people to use IE to load a given page (or a whole site) whether they want to or not.

Sadly, this usually isn't a design move that you can just undo, since it's often rooted in other technology decisions. Consider Netflix's Watch Now function, which lets you watch movies streamed from Netflix's online library in a browser. The required plug-in is IE-only, because it uses a security wrapper and codec provided by Windows Media Player. There's no way to change something like that without reworking the entire content delivery mechanism.

Solution:

There are two basic ways to deal with ActiveX being an IE-only issue, aside from mandating the use of IE:

A. Move away from ActiveX entirely. Again, this isn't always something you can declare by fiat -- especially if the decision to use or not use ActiveX isn't something that is in your hands. If you have the clout to do so, suggest as many non-platform-specific alternatives as you can. Solutions written in Flash are probably the best substitute for ActiveX multimedia controls, and there are a great many third-party Flash controls to choose from that offer such things.

B. Compel non-IE users to use ActiveX compatibility controls. This seems like an interim solution at best. It is possible for Firefox users to run ActiveX controls using a Firefox plug-in, but a given user might not be in a position to install said control, and even if they are, they may not want to do that.

5

User Interface And Keybindings

This is a relatively minor issue, but one that became significant for me when I tried to write an Ajax-based chat application that used it. It's possible to bind hotkeys (Alt + a given letter key) to certain Web controls, like form buttons, by using the accesskey attribute for the control in question.

The problem is that the browser isn't always obliged to implement the chosen access key, especially if it overrides an existing browser command. The way the hotkey is invoked also varies from browser to browser -- and even varies among iterations of a given browser. In Firefox 1.x, the default was Alt + hotkey; in FF 2.x, it's now Shift + Alt + hotkey. It's possible to reset the default behavior with an about:config hack -- change ui.key.contentaccess to 4 -- but I've found people aren't always willing to make changes like that for the sake of a couple of sites.

Solution:

Because of the scattershot way this feature's implemented, it's best not to rely on it for anything, but simply to provide it as an adjunct to existing functionality. Another way to handle it is not to use accesskey at all, but to use cross-browser JavaScript to trap keystrokes and implement focus changes or commands as needed.

6

Planning For The Future

Obviously, it makes sense to find and deal with any existing issues in these categories -- but that's not going to be enough. There are too many ways things can go wrong when developing a site; and it can take hours to track down an issue and figure out a fix. Avoiding problems is a lot simpler and takes a lot less time.

Solution:

I've compiled several key pointers to stick with as you create new sites or revamp current ones.

A. Test, test, test. The only real long-term way to deal with the possible quirks between browsers is to vigorously and thoroughly test any site you're responsible for in all the major browsers, side-by-side, and see what happens. Work with your own sites across the major browsers -- don't just passively browse, but try to actually get things done and see what happens.

On Windows, it's not difficult at all to get IE 7, Firefox, and Opera all running side-by-side without stepping on each other's toes; Firefox is even available in a portable edition for those who want to run it without installing it. (Opera comes in a portable version, too.)

If you're not currently running Windows but are forced to test compatibility with IE anyway, there are a couple of solutions. A fairly elaborate series of hacks exist to run IE on top of Linux through the WINE compatibility layer, although it only works for IE 6 and lower. Another solution involves the use of a virtual-computing product like VMware or VirtualBox to run Windows itself. Interestingly enough, Microsoft provides a virtual hard-disk file that contains a fully licensed (albeit time-limited) installation of Windows XP SP2 with either IE 6 or IE 7 available on it -- useful if you don't have, say, an MSDN subscription.

Also be sure to validate any code you create, since browsers have different ways of recovering from a broken piece of HTML, and you don't want to be at the mercy of such mechanisms. While debugging an older site, I tried to figure out why a given page wouldn't load at all in Firefox, while IE rendered it spotlessly. A quick pass with an HTML validator showed the problem: a table was missing its closing < /table > tag. When I supplied the missing tag, all was well again. Apparently, IE is a bit more forgiving about tables that have missing tags, at least when dealing with the quirks-mode formatting of most existing Web pages.

B. Pick a standard and stick with it. IE may have a big installed base, but coding for IE first is not something you should do unless you have been ordered to do so. My own habit has been to use Firefox as the baseline for everything -- since more browsers tend to render like Firefox than they do IE -- and then make any IE- or other browser-specific fixes after that. If you're in the process of re-centering everything on Mozilla standards, IBM has a long and detailed document in their developerWorks library about how to transition Web docs from IE to Mozilla, including a number of general cross-browser tips.

C. Annotate and warn. If you have implemented things you want to support but simply cannot get them to work properly across the board, at least make sure the people accessing your site know about it or can look it up somewhere. If you know certain functions won't work in IE, you can use a browser-detection routine (see below) to insert a notice to the effect that some features may be degraded in certain browsers. Better to tell them up front than to let them find out on their own!

D. Pick a browser and make everyone else stick with it, too. This isn't likely to make you popular with many people, but if you have specific reasons for working on one and only one browser, it is possible to enforce this rule. Just be prepared to get plenty of hate mail, as few people like being bullied into using any specific browser.

Note that simply evaluating the browser's user-agent string, while useful, will not tell you if a given browser is what it says it is, since the browser can claim to be anything at all. Use an object test on the client side to get a slightly more accurate picture. One quick and dirty way I tested for IE vs. everything else on one of my sites was to use a bit of JavaScript on the client end to see if window.ActiveXObject was supported by that browser. If it was, it was probably IE. If not, it probably wasn't.

E. Keep an eye on the future. Web "standards," and especially their implementations, aren't static things. Even a small change to the right of the decimal point can affect the way things render or behave. Stay abreast of those changes whenever you can, so that you can counter them proactively instead of reactively.