earthli is now sporting a state-of-the-art browser-detection technology, described below. If you'd like, you can <a href="http://www.earthli.com/software/downloads/browser.zip" title="earthli Browser Detector (source and docs)">download</a> it (PHP version only, full documentation included), read the <a href="http://www.earthli.com/software/browser/public/webcore/util/BROWSER.html" title="public class documentation">class documentation</a> online (<a href="http://www.earthli.com/software/browser/developer/webcore/util/BROWSER.html" title="public class documentation">developer documentation</a> also available) or check out the <a href="http://www.earthli.com/software/browser/developer/__filesource/fsource_browser.php.html" title="PHP file source for BROWSER class">source code</a>. <h>Browser Detection Technology</h> The earthli Browser Detector is (hopefully) the last word in browser-detection technology. It provides the standard information like browser name and version, operating system name and version, but it goes further. In order to properly detect a browser, the actual browser name doesn't matter so much; it's the technology driving the browser that is of interest. That's why the earthli Browser Detector does its absolute best to determine which renderer (and version of the renderer) is being used. The name and version are also recorded, but are used only to identify the browser: they are not used to determine capabilities. This separation of the notion of browser and renderer makes this class much more resilient to version and name changes in newer browsers, because often the underlying technology hasn't changed at all. This browser detector should be quite forward-compatible. In addition, deliberately spoofing browsers (like Opera) are also correctly identified (but the detector can only determine information from the user agent string, so if a user agent truly leaves off any information about itself and just uses another browser's string, then, yes, this detector is fooled as well). It's only when a new technology comes along that the class needs to be materially updated (and it is quite simple to plug in support for a new renderer - a single table entry suffices for most of the renderers). <h>How does it work?</h> After careful analysis of an <a href="http://www.pgts.com.au/pgtsj/pgtsj0208c.html">enormous list of available user agents</a>, it's obvious that most browsers identify some browser compliance strings, then specify their actual renderer, then specify a more specific name-brand browser name and version. Some browsers also list plugins after the main browser id (notably IE and descendants). The algorithm finds all name/version strings (according to a regular expressions built from analysis of the user agent list). Then, for each name/version pair, it asks: <ol> Is this a recognized rendering technology?<ol> Is this renderer more specific (important) than the currently recorded one? If so, record the name and version as the renderer for this browser.</ol> Is this an ignored name? (some names are known to correspond to protocols (SSL), operating systems (Linux) or plugins (HotBar))<ol>If not, then record this as the name and version of the browser.</ol> Is this a system name known to provide operating system information? (Linux browsers often include the version of linux) <ol>If it is, extract the name and version for the OS and record it.</ol> Finally, examine the user agent to determine the OS. This step is used to extract and map a commonly known OS identifier for each user agent. It is used in addition to the system information determined above (though many user agents don't specify an OS version). For example, many user agents have Windows NT 5.0 in them. This step will map that to Windows 2000. The actual system name and version are also still available. </ol> As you can see from the algorithm, the basics are in place. Support for future browsers and user agents involves adding or changing information in the 'ignored', 'renderer', or 'system' tables rather than going back into the algorithm itself. <h>How was this class tested?</h> The Phoenix browser provides a preference to change the user agent transmitted in the HTTP header. This was used along with <a href="http://www.pgts.com.au/pgtsj/pgtsj0208c.html">aforementioned list</a> of user agents to spoof as many different browsers in testing. <h>How is this class used?</h> All properties determined in the analysis phase are available, but should be used mostly for displaying browser information to a user. In order to determine whether a feature is supported, it's best to use the 'supports' function, which returns whether certain web features (like DHTML, CSS1, Javascript, etc.) are known to be available with the detected renderer. There is also the 'is' function, which returns whether a browser is claiming to use a certain rendering technology or operating system. <h>What about porting? Is this PHP only?</h> The implementation is PHP only, but the algorithm is quite language-independent and can easily be ported to any other language with regular expressions --- JavaScript, for example. Someone (oalgar) also pointed out that this would be eminently useful as a web-service. That is now in the works and will be announced when it is available.