To create a cross-browser compatible website: 1. Use only standard compliant coding.

2. Don't use browser specific (proprietory) HTML tags and features.

These only work in the browser they were created for and may even break your web page when viewed in another browser. 3. Validate your web pages.

Validate your HTML/XHTML coding using the W3C free validation service Validate your cascading style sheets using the W3C free validation service

Some have the "You can't please everyone" attitude. Yes, your site will look different in each browser because each one interprets the coding differently. The goal with cross-browser compatibility is to make your site viewable in the major browsers available and have the pages render correctly. One thing that will drive visitors away is a site that doesn't work in their chosen browser. If we think about the theoretical part of web development, it seems simple to perform. But many times, after coding, when we test the web page in different browsers it doesnt look same on every browser. Practically, this thing is not simple. Different browsers exhibit HTML and CSS in different ways. So, while doing website designing, designer should have consideration of one of this most important factors to make the website successful. Cross Browser Compatibility is really an important factor of website development. It ensures to display your website consistent across all the browsers. This Cross Browser coding is not an easy task. Here we have some tips for cross browser coding.

1) Keep It Simple
If your HTML or CSS coding is complex, then this will surely create problem in browser compatibility. When you are in design stage of your website, keep the layout simple. Never use too much elements in your markup coding. For example, avoid using a series of p elements to create a menu, just use ul and li to create a menu.

2) Code validation
Before uploading your website, dont forget to use validators to check HTML and CSS coding. Because if there will be any invalid code, it can produce such a problem in your site that will be very hard to sort out. There are HTML Validators and CSS Validators and also some browser plug-ins like HTML Validator Firefox add-on to check your web pages.

3) Avoid quirks mode of browser

Quirks mode duplicates the older and faulty version of the browser. This makes older websites to do task with new browser and there is no recoding of their pages. Quirks mode can create problem when you are building modern pages while browser submit the page in older version.

4) Use CSS reset rules

Most of the browsers have default settings of the things like margin and padding around element. These default settings can create problem in other CSS rules. Make CSS rule consistent across all browsers.

5) Develop in FirefoxTest your website in one browser when you develop the site, and then test it in another browser which is popular. Its better to test your site in one browser like Firefox as this browser is very nice in all respect. And when you, as a developer, is satisfied and happy with Firefox then test your site in Internet Explorer ,Opera ,Safari etc. Although , there will be some issue in Internet Explorer by the website already tested in Firefox, but still, it is better to do HTML and CSS coding which works in Firefox and then test it for Internet Explorer.

6) Test website in different browsers

As all new browsers have some quirks mode, so it is necessary to test your site in different browsers like Internet Explorer 6,7,8 ; Firefox, Opera etc.

7) Make Internet Explorer 6 to work with transparent PNGs

Transparent PNGs are image files through which you can do translucency and smooth borders in background of your website. By default, IE 6 doesnt display transparent PNGs. So, make it work with transparent PNGs.

8 ) Sort out IE issues by using conditional commentsSometimes after creating a beautiful web design that works in Internet Explorer, you still need to adopt some CSS or JavaScript hacks. But there is an alternative of this. Use conditional comments which are much better than hacks.

9) Provide FallbacksThere are some browsers that support JavaScript and Flash and all supporting images. In this case where these features are not there in browsers, it is better to provide fallbacks.

10) Manual CodingTo make your website browser compatible, the idea of hand coding of CSS and HTML is best. Use of software for this purpose is not a good idea. This tutorial explains why you may be seeing browser display errors and recommends steps to avoid these problems. The Browser Photo service helps you know if you have browser display errors by showing you actual snapshots of your page under different browsers, computers, and screen resolutions. HTML Toolbox shows you whether display errors are due to browser compatibility problems or HTML code errors. HTML Toolbox has a one-click repair feature that repairs most coding errors, but in some cases your display problems may be due to other factors. What Causes Browser Display Differences?
Different Browsers Different Browser Versions Different Computer Types Different Screen Sizes

Different Font Sizes HTML Errors Browser Bugs

What You Can Do

Set a Goal Stay Away from Cutting Edge HTML Check Browser Compatibility Validate Your Pages Trial and Error Debugging

What Causes Browser Display Differences?

Different Browsers Your Web browser is a translation device. It takes a document written in the HTML language and translates it into a formatted Web page. The result of this translation is a little like giving two human translators a sentence written in French and asking them to translate it into English. Both will get the meaning across, but may not use the same words to do so. The basic rules for translating HTML documents are established by the World Wide Web consortium, which publishes the official HTML standards. But there's considerable room for interpretation within those ground rules. For example, the HTML standards say that the TABLE tag should support a CELLSPACING attribute to define the space between parts of the table. But standards don't define the default value for that attribute, so unless you explicitly define CELLSPACING when building your page, two browsers may use different amounts of white space in your table. In addition, the HTML standards usually run ahead of what the browsers support. No browser as yet supports 100% of the HTML Version 5 standard, but some browsers come closer than others. Over the past few years Internet Explorer has done a much better job of this than Netscape Navigator, though Opera has done arguably the best job. But since support for the latest HTML tags isn't universal, you could be building your pages with parts of the language that not all browsers understand. In that case the browser will ignore that part of your page it can't translate, and the way your page displays will be affected. This problem is further complicated by browser-specific "HTML extensions." Back during the heyday of the Browser Wars, both Netscape and Microsoft tried to get a competitive edge by running ahead of the HTML standards, inventing their own tags and attributes.

The theory was that Web designers would fall in love with these attributes and put little buttons at the bottom of the page saying, "Best viewed with Netscape Navigator." So Internet users would rush to download that browser and, voila, Netscape would win the Browser Wars. In practice no Internet user will download a new browser just to view your Web site, so these HTML extensions only created headaches for Web designers. The best way to minimize these problems is to pay attention to browser compatibility when building your Web page. Avoid using HTML extensions and be careful about using cutting-edge features of the language that may not yet be supported by all the major browsers. We also recommend you test your pages with HTML Toolbox and review its Browser Compatibility report. Different Browser Versions The major difference between two versions of the same browser is their support for newer portions of the HTML language. A new browser is generally better at displaying Web pages than an old one. However, Internet users tend to upgrade their browser based on the addition of new features, like email integration and instant messaging. If a user doesn't care about these features, they're happy to keep surfing the Web with their old browser.

That presents a problem for Web designers, because for some length of time after the new browser appears, a significant minority of people will still use the previous version. So rushing to build pages with the HTML features supported by the new browser will have to wait. A good rule of thumb is to design your pages to work for the last two versions of the major browsers. While a handful of people use browsers older than that, their numbers aren't large enough to justify the sacrifice required to support them. A few people still use Version 3 browsers, but these browsers don't support Cascading Style Sheets, which are the most important addition to HTML in the last 6 years.

Also note that new browser versions sometimes represent major changes in a browser, and in these cases all bets on the browser's behavior are off. For example, Navigator Version 6.1 is a complete rewrite of Netscape's browser, so a page that worked well under Navigator Version 4 may not work under Version 6. That's especially true if you use Dynamic HTML on your pages. Different Computer Types The Macintosh is still used by 12% of computer users, and has a very loyal following among graphic designers and publishers. In theory, if you view your page on both a PC and a Mac using the same version of the same browser, it should display the same, right? In practice that's rarely the case. There are three reasons for this:
Font Availability. When you tell your Web page to use a particular typeface, such as "Arial," you may not always get the font you want. Fonts are a computer resource, and not all computers have the same fonts as your computer. That's true even between different PCs, but it's especially true between the PC and the Mac. If the typeface of your page suddenly changes between these computers, you've probably used a font that isn't available on both computer types. Font Size. The Mac will generally render your typeface in a smaller pixel size than the PC will. That's especially true if you use the FONT tag to set your type size, since this tag uses abstract units to define size. You can avoid this problem is you use Cascading Style Sheets to set your font size in pixels. ac. Internet Explorer. Microsoft outsources the development of Internet Explorer for the Mac, and so to a large extent this is a different browser from the PC version. In particular, the Mac version of Internet Explorer is prone to quirks and bugs that you won't see in the PC version. If you check your Web page under only one browser on the Mac, do so under Internet Explorer!

Our free Webmaster Tips Newsletter archive contains a number of important tips for avoiding problems between the PC and Mac. Different Screen Sizes If you don't test your pages using different screen resolutions, your page may be stretched to fit a large screen, or be cropped to fit a small screen. Many experienced Web designers use HTML tables to control their page layout, yet they design their pages on large, 1024x768 pixel screens. When these pages are displayed on smaller computer screens, the browser may not be able to fit all the content onto the screen. In these

cases, the content will scroll of the right of the page. While this may not sound like much of a problem, users hate scrolling left and right to view a page. This problem should be easy to avoid, yet a surprising number of otherwise well-designed Web sites don't fit within the standard 800-pixel PC computer screen. This is especially a problem for pages built by graphic artists using a Macintosh, whose standard screen size is 1024x768. Many designers forget that designing for an 800-pixel screen means using roughly a 750-pixel layout. Many less experienced Webmasters design their pages without tables, or dimension their tables to fit 100% of the screen width. If you've built your Web page this way on a computer with an 800-pixel screen, you may be surprised how your page is stretched to fit a larger screen. Text and graphics that were adjacent on your smaller screen may not be so on a large screen. To avoid this, wrap the content of your page inside a single, large, one-cell table. Set the width of this table to be about 560-pixels, if you're designing for a 600 pixels layout, or 750-pixels if you're designing for an 800 pixel layout. Because the majority of Internet users have a screen resolution of 800 pixels or less, it's a bad idea to design your site for a larger screen. Different Font Sizes Most browsers allow users to customize their default font size. Many users who work on computers all day do this to reduce eye strain. As a result, user preferences may cause the typeface that you used to design your Web page to increase as much as 50% larger in a user's browser. This increase in font size can hurt many carefully-planned page designs. HTML Errors Whether you're an HTML coder who builds Web pages by working with the raw HTML tags, or a designer using a WYSIWYG editor like FrontPage or Dreamweaver, the odds are your finished Web page will contain HTML errors. We've tested over 52 million Web pages at NetMechanic. A recent sampling of results from our HTML Toolbox showed that a shocking 85% of these pages contained at least one HTML error! Does that mean that 85% of Web pages are broken? Probably not, but it greatly increases the chance that these pages will have browser display problems. An HTML error is some spot on your Web page where you've violated the official rules of HTML. For example, you may have two tags that overlap one another in a way that the standards say isn't legal.

In practice, the major browsers are robust and forgive many of these HTML errors. But not all browsers forgive the same errors. So your favorite browser may display your Web page without error, but another browser may be seriously affected by the same error.

For example, look at these images. The HTML code on this page forgets to close a single TABLE tag, which is a violation of the HTML rules. Internet Explorer forgives this error and displays the page correctly; Netscape Navigator can't recover from the errors and doesn't display the page at all! The best way to avoid HTML errors is to validate your Web page with a tool like HTML Toolbox. A validator will scan your page and spot areas where you've violated the rules of good HTML. Correcting these errors and following the rules of good HTML goes a long way toward eliminating browser display errors. The free sample of our HTML Toolbox will give you a full validation report on your Web page. The subscription version of this service can also automatically repair the majority of HTML errors it finds on your page. We don't guarantee that HTML Toolbox will cure all your problems, but it will save you hours of time spent solving these problems by hand. Browser Bugs As you've probably seen by now, building a Web page that displays well on all browsers isn't easy. To make matters worse, sometimes you've done everything right, and your page still doesn't display correctly under one specific browser. It's not your fault - you've just encountered a browser bug. Unfortunately, browser bugs are a fact of life for Web designers. Each browser has its own unique set of errors and quirks that you have to adapt to. That's especially true with Version 4 of Netscape Navigator, whose early editions were rushed out the door to beat Internet Explorer to market. A columnist for WebReference recently called Navigator Version 4 "truly terrible browser."

For example, take perhaps the most widely encountered browser bug in existence. The HTML standards say that when you build an HTML table, you don't have to explicitly close each table cell with a closing </TD> tag. This closing tag is optional. Yet unless you explicitly close your table cells, Navigator 4 will not display your table if it is nested inside another table. Since nesting tables is common practice to control page layout, this bug wrecks many well-designed pages. Netscape isn't the only browser prone to bugs. Internet Explorer for the Macintosh has a number of bugs and quirks in the way it handles text spacing. When you encounter a browser bug, it often means resorting to trial-and-error debugging to remove the problem. But before you resort to that, check our free Webmaster Tips Newsletter archive. It contains many tips related to browser bugs that can save you valuable time. What You Can Do We wish it were easy to cure browser display problems, but fixing them takes time. Read the following steps to learn what you can do to make it easier. Set a Goal First, understand that it's hard to build a Web page that displays perfectly on every version of every browser running on every computer. And doing so may require you to leave out features that you really, really want to have on your Web page. Building a Web page that's compatible with Version 1.0 of every browser would mean building a bland page filled with plain text. So the first step to solving browser compatibility problems is to determine which browsers really matter to you. To some extent we've done this for you in Browser Photo, since we don't include very old browsers such as Internet Explorer Version 3, or Netscape Version 2. While a handful of people still use these browsers, there aren't enough to justify the pain required to design pages for them. But what about WebTV and Opera? We've included these browsers because they have small, but fiercely loyal followings. To quote one WebTV user, "We may be small in numbers, but build a site that's WebTV friendly and word gets around."

Within our own site, we track the pages typically viewed by WebTV users, and optimize those pages to work for that browser. Other pages aren't optimized for WebTV. You may decide to do the same for your site, or you may decide that not enough people use these browsers to justify supporting them. In either case, define a goal and design toward it. Avoid the Cutting Edge The Web is hip; it's hot and exciting; it's radical. So many Web designers feel they have to build cutting-edge features into their Web page. That's a bad idea, because cutting-edge features are rife with browser compatibility problems, not to mention the impact they have on your page load time. Web designers typically go through three stages of maturity: (1) I'm just learning; (2) I know it all, and I'm going to prove it by filling my site with cutting-edge features; (3) I've been burned by browser display problems, and only use what's compatible. Not convinced? Try this exercise. Take some of the most well-known sites on the Internet: Yahoo, eBay, Amazon.com. Now go to those sites and look at their HTML code. You won't see many cutting-edge features here. You won't see them using Java or Dynamic HTML. You won't see Flash. You will see Javascript and Cascading Style Sheets. And most of all you'll see well-designed pages that work under all major browsers. Including cutting-edge features in your site doesn't guarantee compatibility problems, but it greatly increases the chance of browser display errors. If you really feel you need to include these features, it's essential to test your pages under all major browsers. Check every page carefully with Browser Photo. Pay Attention to Your Browser Compatibility Report HTML errors are the leading cause of browser display problems. Making sure your Web pages are error free is one of the most important steps you can take to solve browser display problems. That means running an HTML validator, like HTML Toolbox, over every page in your site. The free sample of our HTML Toolbox will give you a full report of all the HTML errors on your Web page. The subscription version of this service can also automatically repair most HTML errors it finds on your page.

HTML Toolbox isn't a silver bullet; we don't claim that it will solve all of your browser display problems. But using it can dramatically reduce the time your spend tracking down browser display problems. Validate Your Pages Next to HTML errors, compatibility problems are the leading cause of browser display errors. We've already warned you about including cutting-edge features in your site, but compatibility dangers extend to all aspects of HTML. HTML Toolbox includes a Browser Compatibility report that will identify HTML tags and attributes that aren't compatible with the three most recent versions of Netscape Navigator and Internet Explorer. Check this report and avoid HTML tags that aren't compatible. Trial-and-Error Debugging While HTML Toolbox can solve many browser display problems, there are some problems it can't address. That's especially true if these problems are caused by browser quirks and bugs. In these cases you'll have to track down your HTML problem yourself. Be patient; you can expect this process to take anywhere from one to four hours. Try following these steps to track down the cause:
1. Make a copy of your Web page so you can restore it to its original form if you need to. Debug this page, not your original Web page. 2. Isolate the problem on your copied page. Do this by eliminating as much of the page as you can. Is the problem at the top of your page? Then throw away everything but the top section of the page. 3. View the pared-down page in the problem browser (use Browser Photo to do this if you need to). Is the problem still there? Then remove more of the page. Eventually you'll get to a point where the problem disappears. In that case, the last part of the page you deleted probably caused the problem. 4. Now go back to your original page (or create a fresh copy of it and work with that). Look at the section of HTML that may have caused your problem. Change it. 5. Now start a new Browser Photo session for your page. View the results and see if you've corrected your display problem. If so, congratulations! 6. After you've fixed the problem, be sure to review your Browser Photo snapshots for other browsers too. It's a common mistake for HTML coders to fix a problem under one browser, and in the process break

the page under another browser. 7. Don't expect your first guess to solve the problem. More often you'll have to try a number of different things to see if they solve the problem. Again, be patient with yourself; this takes time.

Why do you care about Browser Compatibility? Web sites reflect the company's professional image. If your site renders improperly or not at all, your company's reputation can be tarnished. If your site has browser display problems, visitors and potential customers will leave your site and not look back. In contrast, a professional looking site will make visitors feel more comfortable, stay longer and browse more pages. And because of this increased credibility, they are more likely to purchase the products and services that they are looking for from you. A simple purchase of HTML Toolbox and Browser Photo can protect your site from preventable errors, maintain your professional image, and increase you

A useful but often overrated JavaScript function is the browser detect. Sometimes you want to give specific instructions or load a new page in case the viewer uses, for instance, Safari. If you're new to JavaScript, don't use this script. Please read the object detection page first.

Example
Let's detect your browser: You're using Firefox 3.6 on Windows!

The script
Copy this script into your JavaScript files. It works immediately, and you can query three properties of the BrowserDetect object:
Browser name: BrowserDetect.browser Browser version: BrowserDetect.version OS name: BrowserDetect.OS

var BrowserDetect = { init: function () { this.browser = this.searchString(this.dataBrowser) || "An unknown browser"; this.version = this.searchVersion(navigator.userAgent) || this.searchVersion(navigator.appVersion) || "an unknown version"; this.OS = this.searchString(this.dataOS) || "an unknown OS"; }, searchString: function (data) { for (var i=0;i<data.length;i++) { var dataString = data[i].string; var dataProp = data[i].prop; this.versionSearchString = data[i].versionSearch || data[i].identity if (dataString) {

if (dataString.indexOf(data[i].subString) != -1) return data[i].identity; } else if (dataProp) return data[i].identity;

} }, searchVersion: function (dataString) { var index = dataString.indexOf(this.versionSearchString); if (index == -1) return; return parseFloat(dataString.substring(index+this.versionSearchString.lengt }, dataBrowser: [ { string: navigator.userAgent, subString: "Chrome", identity: "Chrome" }, { string: navigator.userAgent, subString: "OmniWeb", versionSearch: "OmniWeb/", identity: "OmniWeb" }, { string: navigator.vendor, subString: "Apple", identity: "Safari", versionSearch: "Version" }, { prop: window.opera, identity: "Opera" }, { string: navigator.vendor, subString: "iCab", identity: "iCab" }, { string: navigator.vendor, subString: "KDE", identity: "Konqueror" }, { string: navigator.userAgent, subString: "Firefox", identity: "Firefox" }, { string: navigator.vendor, subString: "Camino", identity: "Camino" }, { // for newer Netscapes (6+) string: navigator.userAgent, subString: "Netscape", identity: "Netscape"

}, { string: navigator.userAgent, subString: "MSIE", identity: "Explorer", versionSearch: "MSIE" }, { string: navigator.userAgent, subString: "Gecko", identity: "Mozilla", versionSearch: "rv" }, { // for older Netscapes (4-) string: navigator.userAgent, subString: "Mozilla", identity: "Netscape", versionSearch: "Mozilla"

} ], dataOS : [ { string: navigator.platform, subString: "Win", identity: "Windows" string: navigator.platform, subString: "Mac", identity: "Mac" string: navigator.userAgent, subString: "iPhone", identity: "iPhone/iPod" { string: navigator.platform, subString: "Linux", identity: "Linux"

}, {

}, {

},

}; BrowserDetect.init();

This script will only continue to work if you regularly check whether newer browsers still follow the rules set forth in the dataBrowser and dataOS arrays.

Browser detection
The dataBrowser array is filled with objects that contain the properties that help the script detect your users' browser. Note its general syntax:
dataBrowser: [ { prop: window.opera, identity: "Opera" // note: no comma

}, { string: navigator.userAgent, subString: "MSIE", identity: "Explorer", versionSearch: "MSIE" // note: no comma } // note: no comma

];

The [] define an array literal, and all of its elements are object literals. Each object literal is enclosed in curly braces {} and contains a few properties (name: value,). Note that a comma between the objects and between the properties is required, but that the last comma is always forbidden.
Properties

Every object in the dataBrowser array can contain the following properties:
1. string and subString properties. These say: "search for subString in string". If the subString is found, the browser is identified. 2. a prop property. It says "see if prop is supported". If it is, the browser is identified. 3. an identity string. This string becomes the value of BrowserDetect.browser. 4. a versionSearch string. This is for searching for the version number (see below). If this property is absent, the identity string is used instead.

Every object must contain either 1 or 2 (never both!), must contain 3 and may contain 4.
Example: Safari

As an example, here's the Safari object:

{ string: navigator.vendor, subString: "Apple", identity: "Safari"

},

The script takes the value of navigator.vendor and sees if it contains the string "Apple". If it does, BrowserDetect.browser is set to "Safari" and the browser detection quits. If it doesn't, the script moves on to the next object.
Example: Opera

The next object is Opera:

{ prop: window.opera, identity: "Opera" },

Here the script checks if the property window.opera exists. If it does, BrowserDetect.browser is set to "Opera" and the browser detection quits. If it doesn't, the script moves on to the next object.

userAgent and vendor

The trick of browser detection is knowing where to look for the information you need. Traditionally we use navigator.userAgent. However, precisely because this check is traditional many minor browsers change their navigator.userAgent string so that bad detects written by amateur web developers are fooled into identifying it as Explorer. Section 3D of the book discusses this problem, as well as some gory details of navigator.userAgent. More recently, new browsers have started to support the navigator.vendor property, which contains information about the vendor. In general I prefer to use this string for my detection, since it's less contaminated by obfuscation. Of course, as soon as amateurs start using my detection script to detect Safari, Opera, Konqueror or other browsers, the browser vendors will be forced to change the value of navigator.vendor and my detect will not work any more.
Detection order

The objects in dataBrowser are used in the order they appear; that's why dataBrowser is an array. As soon as a positive identification is made the script ends, and it doesn't check the remaining objects. Detection order is very important. The general rule is that you check for the minor browsers first. The reason is that many minor browsers give their users the opportunity to change identity in order to work around browser detects. For instance, the Opera navigator.userAgent may contain "MSIE". If we'd check for Explorer first, we'd find the "MSIE" and would incorrectly conclude that the browser is Explorer. In order to avoid this false detection, we should check for Safari first. If the browser is Opera, the script never proceeds to the "MSIE" check. Safari's navigator.userAgent also contains "Gecko". This causes the same problem: a check for Mozilla would reveal "Gecko", and Safari would be identified as Mozilla. Therefore the Mozilla check only takes place if the browser is not Safari. If you add a new object to detect a new browser, always add it before the Explorer/Mozilla objects at the end of the array.

Version number
In general, the version number of a browser can be found directly after its name in navigator.userAgent. The script searches for this name and takes the number that appears after it. For instance, this is Konqueror's navigator.userAgent:
Mozilla/5.0 (compatible; Konqueror/3; Linux)

The script searches for the string "Konqueror", skips the next character, and takes the number after that. This is the version number. The script uses parseFloat, so that decimal places in the version number also become part of BrowserDetect.version. Unfortunately Safari's string never contains its official version; only its internal Apple version number (ie. not 1.3.2 but 312.6). Therefore the version number detect doesn't work in Safari. Since this is clearly Apple's fault (it doesn't follow established conventions), I don't care.

versionSearch

In general, the browser name as it appears in navigator.userAgent is the same as the identification string. If the browser is "iCab", the script searches for "iCab". However, Explorer needs "MSIE", Mozilla needs "rv", and older Netscape versions need "Mozilla". In order to accomodate these problems you may add a versionSearch property to the browser object. If it's there it's used for the version detect; if it's not there the identity string is used instead. Take the Firefox and Explorer objects:
{ string: navigator.userAgent, subString: "Firefox", identity: "Firefox" string: navigator.userAgent, subString: "MSIE", identity: "Explorer", versionSearch: "MSIE" },

}, {

If the browser is Firefox, the script should look for the "Firefox" string. Since this is also the browser identity string, a special versionSearch is not necessary. Explorer, however, puts its version number after the string "MSIE". Since I use "Explorer" as identity string, I have to define the versionSearch property as "MSIE".
userAgent and appVersion

The version detect script searches for the browser name in both navigator.userAgent and navigator.appVersion. The reason is iCab: this browser's navigator.userAgent may not contain the string "iCab", but navigator.appVersion always does.

Operating system
The OS detect works the same as the browser detect. Currently all my OS detects use navigator.platform, since this property appears to always contain the correct information.

navigator
Below you see the objects contained by the object navigator. These variables can be read out and give information about the browser and computer of your users. Use this information to add new objects to the browser detect.

navigator.userAgent = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/2 navigator.vendor = navigator.platform = Win32 navigator.appCodeName = Mozilla navigator.appName = Netscape navigator.appVersion = 5.0 (Windows; en-GB) navigator.language = en-GB navigator.mimeTypes = [object MimeTypeArray] navigator.oscpu = Windows NT 5.1 navigator.vendorSub = navigator.product = Gecko

navigator.productSub = 20101203 navigator.plugins = [object PluginArray] navigator.securityPolicy = navigator.cookieEnabled = true navigator.onLine = true navigator.buildID = 20101203075014 navigator.javaEnabled = function javaEnabled() { [native code] } navigator.taintEnabled = function taintEnabled() { [native code] } navigator.preference = function preference() { [native code] } navigator.geolocation = [object GeoGeolocation] navigator.registerContentHandler = function registerContentHandler() { [native code] } navigator.registerProtocolHandler = function registerProtocolHandler() { [native code] } navigator.mozIsLocallyAvailable = function mozIsLocallyAvailable() { [native code] }

One rather interesting statistic that you may wish to find out about visitors to your site is which web browser that they are using. Of course, there are a lot of different browsers and many try to pass themselves off as Internet Explorer in order to get scripts on the page that use primitive browser detection scripts instead of feature detection to function properly. What this means is that many browsers do not identify themselves correctly in the navigator.appname field and so that field is not really useful for detecting which browser is really being used. The following script uses the navigator.userAgent fieldinstead and attempts to determine the correct browser from that. This field can also be set to values that attempt to trick primitive browser detection scripts into thinking that the browser is Internet Explorer instead of whatever browser it really is but the true browser name usually appears somewhere in the field as well and this more advanced browser detection script will only misidentify those browsers that have set out to completely conceal their true identity. The first step in using this script is to select the code from the text box below (there is a highlight all button beneath it to make this easier) and copy it into a file called brsdet.js.
Top of Form

// Brow ser Detection Javascript // copyright 1 February 2003, by Stephen // You have permission to copy and use th // the content of the script is not changed function w hichBrs() { var agt=navigator.userAgent.toLow erCas if (agt.indexOf("opera") != -1) return 'Oper if (agt.indexOf("staroffice") != -1) return 'S

Bottom of Form

You next attach the script into your web page that needs to be able to determine which browser is being used by adding the following code into the head section of your page. <script type="text/javascript" src="brsdet.js"> </script> Now all that remains is to assign whichBrs() to whichever field that you want to contain the browser name. The statement can be used anywhere within the Javascript in your page. For example you might code it like this: var browserName = whichBrs(); You can use the result from this browser detection script for statistical purposes or where you want to provide different information depending on which browser is being used. You should not use browser detection to attempt to determine whether a visitor's browser supports particular functionality since there are dozens of different browsers (this script detects at least 15 different ones correctly) and the features provided by the different browsers changes between versions. Instead you should use feature detection if your script requires the use of a particular feature. // Browser Detection Javascript // copyright 1 February 2003, by Stephen Chapman, Felgall Pty Ltd // You have permission to copy and use this javascript provided that // the content of the script is not changed in any way. function whichBrs() { var agt=navigator.userAgent.toLowerCase(); if (agt.indexOf("opera") != -1) return 'Opera'; if (agt.indexOf("staroffice") != -1) return 'Star Office'; if (agt.indexOf("webtv") != -1) return 'WebTV'; if (agt.indexOf("beonex") != -1) return 'Beonex'; if (agt.indexOf("chimera") != -1) return 'Chimera'; if (agt.indexOf("netpositive") != -1) return 'NetPositive';

if (agt.indexOf("phoenix") != -1) return 'Phoenix'; if (agt.indexOf("firefox") != -1) return 'Firefox'; if (agt.indexOf("safari") != -1) return 'Safari'; if (agt.indexOf("skipstone") != -1) return 'SkipStone'; if (agt.indexOf("msie") != -1) return 'Internet Explorer'; if (agt.indexOf("netscape") != -1) return 'Netscape'; if (agt.indexOf("mozilla/5.0") != -1) return 'Mozilla'; if (agt.indexOf('\/') != -1) { if (agt.substr(0,agt.indexOf('\/')) != 'mozilla') { return navigator.userAgent.substr(0,agt.indexOf('\/'));} else return 'Netscape';} else if (agt.indexOf(' ') != -1) return navigator.userAgent.substr(0,agt.indexOf(' ')); else return navigator.userAgent; } Browser detection allows you to find out what browser your viewer is using, and then perform a script based on it or just to send a friendly message to those with your favorite browser. You might come around a situation when you need to include different Javascript files for different browsers, or call different function. This script will hep you doing that. There are two objects often used for this, the navigator.appName and navigator.appVersion objects. The first one returns the name of the browser, the second returns the version of the browser. If the browser is Netscape, navigator.appName returns the string Netscape. If it is Internet Explorer, it returns the string Microsoft Internet Explorer. Using just this, you could make a script to alert people as to what browser they are using (just to bug them). Like this:
<HEAD> <SCRIPT language="JavaScript"> <!-var browserName=navigator.appName; if (browserName=="Netscape") { alert("Hi Netscape User!"); } else { if (browserName=="Microsoft Internet Explorer") alert("Hi, Explorer User!"); } else { alert("What ARE you browsing with here?"); } } //--> </SCRIPT> </HEAD>

You can do the same thing with the navigator.appVersion, except you will most likely want to grab just the integer from the version information (2,3,4, etc.). To do this, we use the parseInt() function:
var browserVer=parseInt(navigator.appVersion);

Now, it returns only the integer value and not something like version 4.51. It just sends back 4 in that case. Thus, we could alert viewers as to whether their browser is new enough for us or not:
<HEAD> <SCRIPT language="JavaScript"> <!-var browserVer=parseInt(navigator.appVersion); if (browserVer >= 4) { alert("Your browser is new enough for my site."); } else { alert("I think you need a new browser!"); } //--> </SCRIPT> </HEAD>

Of course, you can use both objects to be more exact. You could look for a certain set of browsers and only if they are above a certain version:
<HEAD> <SCRIPT language="JavaScript"> <!-var browserName=navigator.appName; var browserVer=parseInt(navigator.appVersion); if ((browserName=="Netscape" && browserVer>=3) || (browserName=="Microsoft Internet Explorer" && browserVer>=4)) version="n3"; else version="n2"; if (version=="n3") alert("Your browser passes the test"); else alert("You need an upgrade, I think."); //--> </SCRIPT> </HEAD>

It is basically saying that if the browser name is Netscape and it is version 3 or greater, OR if the browser name is Microsoft Internet Explorer and the version is 4 or greater, then we will assign the variable version as n3. Otherwise, it is going to be n2. Then we move on to the rest. One of the more common uses for browser detection is to redirect a viewer to a page made for his/her browser type or browser version. Redirection Using Javascript: Redirection is often used to take viewers to a page depending on their browsers name or version. To redirect a viewer instantly, you just need to add a short command in your head section:
<HEAD> <SCRIPT language="JavaScript"> <!-window.location=http://someplace.com; //--> </SCRIPT> </HEAD> Or you can use <HEAD>

<SCRIPT language="JavaScript"> <!-document.location.href=http://someplace.com ; //--> </SCRIPT> </HEAD>

This would take the viewer right to the url you used as soon as they start loading the page. Sometimes this is done if a site has moved to another location. Another use for it is to detect a browser type and redirect your viewers to one page for Netscape, another of Internet Explorer, or a third for other browsers:
<HEAD> <SCRIPT language="JavaScript"> <!-var browserName=navigator.appName; if (browserName=="Netscape") { window.location=http://www.someplace.com/ns.html; } else { if (browserName=="Microsoft Internet Explorer") { window.location="http://www.someplace.com/ie.html"; } else { window.location=http://www.someplace.com/other.html; } } //--> </SCRIPT> </HEAD>

This uses the browser detection method from the previous section. Rather than popping up an alert box, we redirect the viewer to a page that best suits the browser being used. If you want to have one page for version 4 browsers and another for others, we can take another script from the previous section and change it in the same way:
<HEAD> <SCRIPT language="JavaScript"> <!-var browserVer=parseInt(navigator.appVersion); if (browserVer >= 4) { window.location=http://www.someplace.com/v4.html; } else { window.location=http://www.someplace.com/other.html; } //--> </SCRIPT> </HEAD>

You can also use this to help people who come into your site, but come in on a page that should be within a frameset that you use for navigation. Using the top.frames.length object, you can find out if the page is in a frame or not. If the value is zero, the page is not in a frame. If it is greater than zero, the page is inside a frame. So, you could take the viewer back to your main frameset page using a script like this:
<HEAD> <SCRIPT language="JavaScript"> <!-function getgoing() { top.location="http://someplace.com"; } if (top.frames.length==0) { alert("You will be redirected to our main page in 10 seconds!");

setTimeout('getgoing()',10000); } //--> </SCRIPT> </HEAD>

This will alert the viewer and take them to the main page after 10 seconds. You can change the number in the setTimeout function to adjust the time if you like. You can also use it to break a viewer out of someone elses frames if they followed a link that didnt have the target set correctly. It uses the same idea in reverse:
<HEAD> <SCRIPT language="JavaScript"> <!-function getgoing() { top.location="http://someplace.com"; } if (top.frames.length > 0){ alert("The frames will be broken in ten seconds."); setTimeout('getgoing()',10000); } //--> </SCRIPT> </HEAD>

As you can see, redirection can be a handy tool at times. Just use it with caution if you are worried about the search engines.