One Code Fits All

I
N
T
R
O

hich browser should we consider when writing a Web application? Technically none of them and practically all of them. We should write our code the way that the resulted pages look the same, or at least similar in all modern browsers. Theoretically you just need to follow general, browser-independent standards. "What standards?" you may ask. Unfortunately that's what browser makers asked for decades, too.

The standards

he World Wide Web Consortium, W3C in short, is an independent expert body that sets the rules. They don't issue laws, only specifications and recommendations for meta-languages like HTML and XML, and for styling properties like the ones in CSS. As an organization recommending standards for browsers, they don't create browsers, either. They have an open-source initiative though, on developing an Integrated Development Environment with browser functionality, too. It is called Amaya. Amaya is a Web editor, with the intention to be a comprehensive client environment for testing and evaluating new proposals for Web standards and formats. As of January 2005, it has its version 9.0 with many good editing features but still far from working as a fully functioning browser. Browser makers try to follow the rules that actually don't confront with their schedules and financial interests. After decades of a nasty jungle war browsers tend to agree in the most important issues. The leading browsers, Internet Explorer, Mozilla (Firefox, Netscape) and Opera can display well-written, HTML compliant pages with about the same look and functionality now. The rest is on us, developers. Are we complying? I must say, no. Would you believe that most Web sites don't follow the latest HTML standards? I randomly checked the opening pages of some high traffic sites. Here is the result:

Non-compliant                     HTML 4 compliant
Yahoo.com
AOL.com
Google.com
CNN.com
netscape.com
Amazon.com
eBay.com
expedia.com
msn.com
microsoft.com
ESPN.com

Can you find any compliant sites? Neither can I. Last I tried the official Web site of the President of the United States: http://www.whitehouse.gov/. Guess what, he failed, too. But we can't expect George W Bush to be HTML compliant before Bill Gates.

AOL is the only one with a doctype claiming that its opening page is XHTML compliant but it is not. Bigger mouth, same sloppiness. It does not even follow the less strict, HTML 4 standards. I believe that these companies are just too big to be good. OK, their revenues are breathtaking but can they produce a standard HTML page? After all, they are the Web; theese few transact at least half of all the traffic on the Internet. What about you? Do you think that the only way to get rich is to neglect the rules? Be a man (or a person, politically correcting myself, although it does not make sense) with self-respect and show the big shot organizations that you are better than them. You can develop W3C compliant applications. For one, this is the way to create cross-browser pages. Even if your boss says that the company uses only IE 6, and you don't have to care about other browsers, you should follow the W3C standards. And those rules that I collected in The Web Developers' Ten Commandments. I believe that you will make your life easier. And that of your customers. And that of your colleagues. And the day will come when your employer will be thankful to you. Neah! Too much of dreaming.

The art of cross-browser scripting

n the beginning there was chaos. We developed a nice solution for one browser, then another browser displayed it wrong. We had to create another solution for the other browser, programmatically check the type of the actual browser and depending on the type, branching the execution to one or to the other solution. Then the first browser came up with a new version that worked with the solution written for the second browser. The branching must have been replaced with one that contained version numbers, too. The Internet was crowded with better and worse browser sniffers; codes that detect which version of which type of browser is viewing the page.

Microsoft has been pushy in introducing proprietary objects and properties in Internet Explorer, such as document.all and innerHTML. You can avoid using them but you should not necessarily oppose everything that is not part of the W3C standards. The first one has the practical drawback that no other browsers accept it. The second one carries an excellent idea, and I hope that it will become a standard. The only downside of innerHTML is that someone else invented it, not me. Although it is not part of the W3C DOM, Mozilla- and Gecko-based browsers (such as Firefox and Netscape 6) decided to support it. Most browsers newer than May 2000 understand innerHTML and you can use it liberated.

The situation is clearer nowadays. We don't have to check which one of the numerous browser versions we actually serve. We rather check for functionality. For example, if we want to get or set the value of an object, we can use the getElementById() method in most browsers. Apparently, I don't deal with those older browsers anymore that don't understand the getElementById() method. It works since IE5, NS6, and Opera6. Once a feature survives two version changes of three browsers each, chances are that it will stay for a while. Instead of keeping track of browsers and their versions, we may simply check if the used function works in the running browser. Good developers don't sniff for type and version; they test the browser something like this:

Of course, id has to be the identifier of an existent object, for example of the body of the page. I prefer to run this test at the opening page of an application once, because I can give the warning at the beginning; so, I don't have to run the test over and over again. In some applications, like in an eBook, the author should be prepared that the visitor does not start the reading from the front page. Some like it from the back, others jump in the middle accidentally or intentionally, hoping that there is a centerfold picture there. In these cases, one needs to run the test at every occurrence of the questionable element.

With my present awareness I am supporting IE version 5.5+, Netscape version 6.0+ and Opera version 7+. When I say Netscape, I mean Mozilla throughout these articles. Recent Netscape versions are built on the Mozilla open-source code, as well as many other new browsers, like Firefox. I hope that their common core can assure us that if a solution works in the latest Netscape, it works in other Mozilla-based browsers.

There are still interpretation differences among Internet Explorer, Netscape and Opera. Let's take the treatment of spacing. Netscape and Internet Explorer give the body tag a default margin of 8 pixels but Opera does not. Instead, Opera applies a default padding of 8 pixels, so if one wants to adjust the margin for an entire page and have it display correctly in Opera, the body padding must be set as well. In general, never let the default values kick in. Always set them to your taste. Well, this is easy to say but difficult to do. Not only their default values, the interpretation of spacing between and around objects also distinguishes browsers. The spaces occupied by padding, border and margin are different in different browsers. Their sizes are usually added to the surrounded object's width and height but sometimes deducted. If we also take the scroll bars into account, which have non-adjustable various sizes in various browsers and the sizes of which sometimes are added, sometimes deducted to/from the scrollable objects' sizes, the mess can be big. Internet Explorer 5.x is famous for its broken box model. Padding and border are supposed to be applied outside the box but in IE 5.x they are inside. I am trying to sidestep rather than fight the problem. I consider myself a perfectionist but I would not waste my time for a pixel-perfect cross-browser layout. When the different arrangements all look good in three major browsers, I stop tinkering the layout and I don't try to fix what is not broke. My advice is that try to set all the differently handled spacing to zero or small if possible and avoid designs where displacements by a few pixels add up and become critical. A table row with 20 cells will be off 160 pixels at the end of the row, if a two-pixel padding of the individual cell is not added but deducted.

As a last resort, you need to write various style sheets for various browsers and to go back to the world of browser sniffing. You will find many code samples on the Net. I am afraid that too many, compared to the importance of the issue. If you find your page similar in three major browsers, you may grant yourself the cross-browser compliant award and display its icon as I did below.

When Sniffing Is a Must

rowser sniffing is necessary when you cannot create a general solution that works in every browser you consider. So far, I could overcome the differences among the layouts rendered by different browsers, without handling them differently. I met one problem where I could not avoid the various behaviors of the various browsers, though. I have created a few Web applications that open XML data files. XML is a nice standard for carrying data but loading an XML data file into HTML is still a challenge. Internet Explorer has a relatively simple method, using the Microsoft-only ActivX object. Unfortunately, it does not work in its own IE for Mac. OK, we can forget those few twisted who deny the word of PC's and Windows but stick to Internet Explorer on a Mac. I have a good solution that works in Mozilla browsers, like in Netscape 7 and in Firefox. None of the above works in Opera. Should we neglect the Opera fans? No way! There is a solution for Opera, which actually works in the other two major browser groups, too, even in IE for Mac. It also has its drawbacks but it helped me to complete the jigsaw puzzle. There is cross browser and cross platform solution to loading XML data. The discussion of this solution needs a separate book, or at least a separate article. And I am working on it...