Section B. Incompatibilities

B. Incompatibilities

Which problems do these browsers have? How can we solve them?

Problems

Roughly speaking, there are four categories of browser incompatibilities. The first three are on the way out, now that all modern browsers are serious about implementing the JavaScript standards discussed in 1B. The fourth category, unfortunately, will never disappear.

Not supported

Some browsers don't support some parts of JavaScript. For instance, Explorer and Mozilla allow you to access and change entire style sheets through the document.styleSheets nodeList. Safari allows read-only access, while Opera offers no access at all. (More on this in 9D.)

Browser vendors allocate resources and money to solve specific problems. Usually they have plenty of bugs to fix, and adding an extra feature may be just too much work. This is a perfectly understandable decision, and besides, all incompatibilities in this category are nice-to-have extras, not need-to-have basics.

It's easy to work around unsupported features as long as you start your script by checking whether or not they're supported. We'll discuss the technical nuts and bolts in 3C.

Legitimate differences of opinion

Browsers can have legitimate differences of opinion about vaguely specified areas of the JavaScript language.

The defer attribute of the <script> tag (see 4D for more) is an excellent example. Explorer has a unique take on this attribute, but its implementation can be regarded as a correct interpretation of the rather vague W3C spec.

Since it's impossible to say which browser is right or wrong, such incompatibilities will not be solved any time soon. They're not easy to work around, either, because checking whether a browser supports such a feature doesn't help; all browsers will proudly announce their support but interpret your code differently.

Fortunately, this is the rarest category of incompatibilities.

Deliberate incompatibilities

During the Browser Wars, Netscape and Microsoft each supported their own version of JavaScript, and both vendors deliberately added features the other browser didn't support, and chose not to add features that the other browser supported.

Since that time, the emergence of W3C standards has done much to alleviate the plight of JavaScript developers, but occasionally we still encounter relics from the ancient battlefields, especially in event handling.

Fortunately, these problems are rather easy to solve. Usually the various browsers use different names for the same thingfor instance, Explorer calls the event target srcElement, while standards-compliant browsers call it target. If you check for both names and use the one that's actually supported, you've solved most of the problems in this category.

Once Microsoft gets around to implementing the W3C events standard, we'll have overcome the last significant batch of deliberate browser incompatibilities, and the vendors will only have to do some minor mopping up.

Browser bugs

Browsers are created by humans, and humans make mistakes. These mistakes take the form of unexpected errors (yup, bugs). In fact, the majority of the cross-browser problems you'll encounter are due to bugs. For instance, Explorer 6 crashes on the (rather unimportant) normalize() method. Everybody will agree that this is not the desired behavior, but rather a programming bug that has to be solved.

It's while encountering this elusive and annoying bug category that scripters most commonly develop existential angst and premature hair-loss.

The problem is that it can take quite a while for these bugs to be fixed, because there are so many of them and because some bugs are easier to fix than others.

Not only is the problem unsolvable, it's even unmeasurable. In the technical chapters of this book I'll point out a few of the more obnoxious and well-known bugs, but the list is far from comprehensive. Neither are the compatibility tables on www.quirksmode.org even remotely complete. In fact, there will never be a list of all browser bugs, because creating and maintaining it would be just too much work.

Even if you learn all bugs enumerated in this book and on my site by heart, chances are you'll encounter a new one with the first script you write.

Solutions

With all that said, how bad is it?

For "hard" programmers, who unconsciously assume they have to deal with only one implementation of a language, browser incompatibilities generally come as a nasty surprise. Newbies can react pretty badly, too.

On the other hand, JavaScript is a bug-free haven compared to CSS. The current JavaScript incompatibilities are roughly comparable to the usual mid-level stuff that crops up all the time in CSS development, but without any of the really serious problems. CSS developers already have the basic mindset necessary to become efficient JavaScript browser herders.

Veterans of the Browser Wars don't see any reason to get excited. Today's stuff is distinctly small fry compared to the days when Netscape and Explorer fought their bitter war and browser incompatibilities were impossible to solve.

As you might have guessed, I share that last point of view. To me, browser incompatibilities are simple facts of life that won't disappear any time soon. My general advice is to get used (or at least resigned) to them as soon as possible.

Learning to work with browsers is a necessary component of becoming a good JavaScript developer. Even if you decide to use a library that works around the worst issues for you, you should experience, at least once, the frustration of handling a herd of obnoxious browsers by hand. I advise you to acquire that experience as soon as possible. It'll heighten your awareness of what browsers can do to your scripts.

My "secret"

Nowadays I hardly notice many browser incompatibilities. My "secret," apart from eight years of experience, is my writing.

Back in 1998, when I encountered my first incompatibilities, I set up a simple Web site to describe the problems and their solutions. For years, I kept adding new pages about new incompatibilities, and this has made QuirksMode.org what it is today. In addition, this process fixed problems and solutions in my head to the extent that I can still quote large swaths of obsolete Netscape 4 lore.

Apart from the obvious advantage of being able to look it up later, writing about browser incompatibilities forces you to think logically and order your thoughts so that other people will understand you. This extends your understanding of the problem. In addition, you usually create a few simple test pages to get to the bottom of the bugs, and this, too, extends your understanding.

So my advice is: when you encounter a browser bug, create a test page, write a coherent article, and put both online. It will help you to get a real grip on the problem, it will help other Web developers save their valuable hair, and once you've created enough pages you'll find yourself becoming something of a browser expert, both in your own eyes and those of others.

Day-to-day development

When I create a script, I constantly test every line I write in Explorer Windows and Mozilla. Explorer contains quite a few peculiarities that should be addressed immediately, while Mozilla is an excellent representative of W3C DOM-compliant browsers.

When I finish a script module, I start Safari and Opera (and occasionally Explorer Mac, iCab, and Konqueror) to check for problems. If I find any, I try to solve them, but the amount of time and trouble I take depends on the browser in question.

Essentially I'm willing to take a lot of time for Safari, but not for any of the other browsers. Opera bugs are either easy or impossible to solve, Explorer Mac is too old, and iCab and Konqueror have too little market share. Agree or disagree with my exact browser lineup, but I advise you to make similar decisions or risk total insanity.

Do not under any circumstance write a script for one browser first and add support for the other browsers "later on." This is the fastest way to hell. It's far better to solve nasty incompatibilities at the start of your project than at the end.

When a project starts, you usually have enough energy to spare for the browsers, and everybody expects you to be busy with serious coding, anyway. Conversely, at the end of the project you're tired, and your time is increasingly taken by the small changes that always crop up when deadlines approach. If you still have to solve your browser issues at that time, you probably won't solve them at all, and will instead resort to a browser detect.

Testing time

At testing time I always worry. Sure, right now my script works fine on my computers in my specific browser installs, but that does not mean it will work everywhere.

The obvious solution is to test my script in as many browsers as I can lay hands on. The key is not numbers, but diversity.

Sometimes large testing sessions are performed in-house by employees of your corporate client. Unfortunately, these sessions rarely provide you anything of value. In 2005, I encountered a client who had arranged for no less than 60 people to test their new site. But by sysadministrative decree, they all used Explorer 5.5 on Windows NT 4, even though 6.0 and XP had been available for several years.

This setup was pointless. 5% of the testers saw a weird bug. I wasn't unduly worried by it, and it was a difficult one to solve, too, especially because I couldn't see it myself. I ignored it. My conclusion was that the site worked fine on 95% of the IE 5.5 Win NT 4 installs. That's good to know, but it's not what you'd call exhaustive browser testing.

What you really need is a wide range of browsers and operating systemsnot hard to find in most Web-development companies. Ask your colleagues to test the site for you, and you'll usually get more varied bug reports than when clients test them. Especially try to get reports from different Windows versions; sometimes you'll uncover nasty problems.

If you're in a restricted environment yourself, first complain to your boss. You must have the tools you need to do your work, and that includes Macs and older Windows and Explorer versions.

Alternatively, ask for help at a Web-development mailing list. Usually these lists host quite a few helpful people who are willing to sacrifice a few minutes to check your site, and who more often than not can also give you a clue about the cause of the problem.

Mailing Lists

Evolt, http://www.evolt.org, and Webdesign-L, http://webdesign-l.com/, are good general web-development mailing lists.

For specific JavaScript mailing lists, I can recommend my own list, at http://www.quirksmode.org/dom/list.html, and the JavaScript list at Louisiana Tech, https://lists.latech.edu/mailman/listinfo/javascript.

You should develop a sense of when to stop taking obscure bugs into account. There's always one tester with an absurd browser ("Netscape 6.1 on Mac OS 9! Thousands of people use it!") and another whose Explorer install is corrupt. If you encounter such a situation, just ignore it. It's not worth your time.

Your scripts will never work in 100% of the browsers. Ever. Get used to it.