To FootSee "About This JavaScript Site" in JavaScript Index and Introduction.
The news:comp.lang.javascript FAQ Note Browser Detecting (and what to do Instead) has been used in the preparation of this page.
The material in this page has been collected from other js-*.htm pages on this site, and re-arranged. There may be residual redundancies.
JavaScript in Web pages is executed by the client browser. There are many different browsers in various versions, and there are variations in the extent and the manner in which JavaScript is implemented in them. Coding needs to allow for this.
Attempting to detect what the browser claims to be is at best unreliable, cannot be future-proof, and is deprecated.
Here I consider only coding for pages shown on typical computer browsers. The principles should apply to coding for other devices (mobile phones, etc.); the details may not.
Browsers are designed to indicate their own identity, often by using the navigator.userAgent string, etc. However, they are often set up, by default, to do so falsely. Perhaps a page should honour such a setting as a request.
As well as testing the userAgent string, one can try to identify the browser by testing for specific routines. Therefore, browsers may implement dummy routines ...
When the aim is to write code so that it will work properly on as many browsers as possible, independently of their settings, an author needs to ignore the settings and rely on feature testing to identify what is needed for a successful page.
Rather than testing specifically for browser version (as in Browser Information), it is generally better to test for the existence, and maybe the proper functioning, of specific features before using them.
One commonly sees feature testing used to prevent error messages by omitting code - if TEST(X) then USE(X). That is rather unsatisfactory if X was worthwhile since those without X do not see the result of X (and are unaware that another browser would do better).
Otherwise, there is if TEST(X) then USE(X) else SIMULATE(X) - but if the code for SIMULATE(X) must be provided then why code USE(X)? That seems appropriate only if SIMULATE(X) is inferior.
Generally, there is no need to support Microsoft IE 3 or earlier, or complications with Netscape 4, or other early versions. One can, therefore, assume that, if JavaScript is running, the basic features are present and correct.
But that does not always apply. For example, charities and third-world may still use old systems; computer suppliers should allow for potential customers not having recent computers (a reason for buying).
The usual assumption, in discussing browser detection and feature testing, is that pages are written for the open public Web, and should be fully acceptable on all sorts of machines and browsers in use.
Sometimes, the subject material is such that full compatibility is not a reasonable requirement. If you want to able to use the demonstration or calculation features on many of my pages, you must have JavaScript enabled; I can provide no alternative. Some tables and graphics cannot reasonably be designed for small screens or large magnifications.
Sometimes, in particular with a closed group of viewers, it may be necessary to identify either the browser itself (as far as possible); or to identify and possibly use whatever it claims to be.
Therefore, it may be correct to employ forms of testing which canot be recommended for general use.
Note that it is often not appropriate to test for a feature immediately before use. Instead, test it before showing or allowing a course of action that will need the feature.
I see three classes of testing, but there may be more.
Method window.onerror can be temporarily replaced, to allow the safe testing of dubious syntax, as in RegExp Feature Testing; need a non-RegExp example?
If a method does not exist, referring to it gives undefined. If a function F does not exist, typeof F gives undefined. In a Boolean context is converted to false; otherwise the result converts to true.
Postulate, in a future standard, a method .Back for reversing the content of a String.
That test was performed on a particular String. More generally,
shows that .Back does not currently exist for Strings, but can be added.
Method ToFixed has at least one bug in IE6/7 (but not in Firefox 2, Opera 9 or Safari 3), which can be tested for.
To generate whichever of DD/MM/YYYY and MM/DD/YYYY will be read correctly by new Date(S):-
Functions not provided in earlier browsers can be simulated, if found absent, e.g.
After the last of those, even in a browser without native getElementById but with document.all (such as MSIE 4) one can use document.getElementById('Divn').innerHTML = "Hello<br>World" to write to a unique element called Divn , etc., etc.
By habit, I previously preferred to use function DynWrite ; but, for modularity and ease of reading, one should in any case use a function such as Wryt with parameters like those of DynWrite .
From an Include file of mine :-
Remember that there are significant differences between Netscape 4 and MSIE, and, no doubt, other browsers.
It is normally recommended that one should use feature or object detection in order to make code work with different viewers.
See also Information on your browser - Alan Wood.
Partial information on your Browser :-
My MS IE 7, 2009-07-19 : JScript 5.7.18066
My MS IE 8, 2009-07-19 : JScript 5.8.18702
2009-11-03 : JScript 5.8.22886
Needs more.
var IE = /*@cc_on!@*/false;
<script type="application/javascript;version=1.7"> // put 1.7 ON in FireFox 2