適正でないブラウザ判別法を使うとウェブページ維持にいろいろな支障を来たす悪夢の元となります。効率よく維持できて多くのブラウザで綺麗に見れるクロス・ブラウザの条件を満たすサイトを作るにはいつ、どのようにuser agent判別を使用すべきかの根本を見直すことが必要です。このノーツでは幾つかのブラウザ判別法を取り上げ、各々の利点や役に立つ環境を指摘して一般的に使えるブラウザ判別を探る。
navigator object when detecting Gecko
In an ideal world, we could author HTML, XML, CSS and JavaScript and only worry about the W3C and ECMA standards. However, we don't quite live in such a world yet. Due to bugs, incomplete implementations of the standards and legacy browsers, web developers must be able to determine which browser a visitor is using and provide the appropriate content and scripting code path.
Although browser detection is perhaps the most common scripting task that every web developer faces, it seems that the variety of different strategies in use for detecting browsers is unlimited. As a member of the Netscape Evangelism team who has spent over a year investigating existing web content, I can say without a doubt that most compatibility problems found on the web today are due to a lack of understanding of the standards combined with inadequate and inappropriate browser detection strategies.
This article is intended to provide an overview of browser detection strategies and best practices. For more specific Netscape Gecko TM recommendations, please see the Netscape Gecko Compatibility Handbook.
Although many web developers are aware of Netscape 6 and Netscape 7, far fewer are aware that Netscape 6 and 7 are members of an entire family of user agents based upon Netscape Gecko that includes the commercial browser CompuServe 7, and open source browsers such as Mozilla, Galeon, and Kmeleon.
Netscape Gecko was designed from the ground up to be compliant with the W3C HTML, W3C CSS, W3C XML, W3C DOM, and ECMAScript (JavaScript) standards. It also includes compatibility features which allow it to reasonably handle legacy content which was developed for earlier generations of browsers such as Netscape Navigator 4 as well as features which provide compatibility with Internet Explorer 5 and 6. Unlike other browsers, Netscape Gecko is truly a cross platform browser and provides identical support on all operating systems where it is supported.
The easiest way to support Netscape Gecko is to create content which only uses the standards. Unfortunately, no other browser supports the standards as completely as Netscape Gecko which means that web developers and authors are forced to continue to provide support for other browsers which do not support the standards as fully. Fortunately, other browsers such as Internet Explorer 5 and 6 for Windows, to a lesser extent Internet Explorer 5 for Macintosh and Opera 6 also support the standards to a degree. These other browsers also appear to be moving towards more complete and rigorous support for the standards and there is hope that in the future web developers and authors will be able to dispense with browser detection at least with regard to features governed by standards.
We are still faced with the question of how to develop standards based content while supporting the differing implementations of modern browsers while at the same time supporting (to a lesser degree) older and less capable browsers. Browser detection is key to accomplishing this task.
To understand why many common browser detection strategies are inappropriate, we must first look back on how these strategies came into being.
In the earliest days of the web, HTML was very simple, not standardized and did not include any support for client side scripting. HTML itself was not standardized until HTML 2.0 was introduced in late 1995 and it did not even include tables. Browser vendors such as Netscape and Microsoft competed to add compelling features to the HTML they supported in their browsers in order to provide the richest most compelling content to their users and to entice web authors to support them. The abilities of browsers to support the latest and greatest content changed on an almost daily basis.
Web authors were faced from the beginning with a variety of browsers, some of which supported the latest and greatest version HTML and some which did not. The solution was either to provide the lowest-common denominator of HTML or to use browser detection techniques on the web server to send customized content to each browser depending on what level of support the browser provided. server side browser detection using user agent strings was born.
User agent strings are defined in the HTTP protocol and are available to web servers (see RFC 1945 - Hypertext Transfer Protocol -- HTTP 1.0 and RFC 2068 - Hypertext Transfer Protocol -- HTTP 1.1).
The most common approach at this time was to distinguish user agents by vendor
and version using the reported user agent string.
Although this approach was considered reasonable at the time,
this approach caused problems for browser vendors right from the beginning.
The original Netscape browsers used a user agent string which began with
the code name for the Netscape browser followed by it's version number, e.g.
Mozilla/version followed by a comment token which gave additional
information regarding the operating system being used, etc.
Since the earliest browser detection techniques were based upon looking for
a Netscape based browser and only provided customized content to browsers
which used the Mozilla/version user agent string, other browser
vendors standardized on using Mozilla/version to signal that
they were compatible with a particular Netscape version. Since other browsers
pretended to be Netscape browsers and encoded their version information
in a non-standard fashion in the user agent comment area, the task of
determining which browser was being used became more complicated than it should
have been.
Netscape Navigator 2 introduced the ability to run JavaScript in web browsers.
As browser evolution continued,
differences in the implementation of scripting and the objects supported by
browsers appeared. Web authors were no longer limited to detecting browsers
on their web servers, but could now execute scripts client side (in the browser itself)
which could be used to distinguish browsers.
One of the earliest approaches to client side browser detection involved testing whether
the browser supported particular objects. An example of this approach involved
testing for the existence of the document.images object.
While object based detection was used in some circumstances,
many web authors continued to use the vendor/version approach to
distinguishing web browsers in their client side scripts.
Since the user agent string was exposed as a property of the navigator object
(e.g. navigator.userAgent), many web authors used the same
logic in their client side scripts as they had used earlier in their server side
browser detection. In addition to navigator.userAgent
other properties such as appName and appVersion
were available in the navigator object which could be
used in browser vendor/version detection strategies.
The classic example of this vendor/version client side detection strategy can be found in the Ultimate Browser Sniffer. This script and variants of it can be found today on many web sites where it is a common source of detection problems.
Netscape Navigator 4 and Internet Explorer 4 introduced the ability to manipulate HTML content in a browser (Dynamic HTML or DHTML) rather than on the web server and began the introduction of support for CSS to style content. This generation of browser, in addition to sharing several features which were not available in earlier versions, each implemented their own (incompatible) competing abilities to manipulate content in a web page.
Since each vendor's browser implemented different objects to perform DHTML,
web authors began to use object detection to distinguish
vendor/version through the existence of particular JavaScript objects.
The existence of document.layers was sufficient to
be sure that the browser was Netscape Navigator 4 while the
existence of document.all was sufficient to be
sure that the browser was Microsoft Internet Explorer 4.
An implicit assumption by many web authors around this time was the there
were only two types of browser available... Netscape Navigator and
Microsoft Internet Explorer.
These strategies of classifying browsers by vendor/version, assuming that the only browsers being used where either Netscape Navigator 4 or Internet Explorer 4 failed when alternative browsers such as those based upon Netscape Gecko were introduced. Many of the problems reported in the press regarding Gecko's inability to display content were directly related to inadequate, inappropriate browser detection strategies.
A final note on vendor/version strategies. A web developer who fully utilizes the browser detection and distinctions in the Ultimate Browser Sniffer will produce code which uses code forks for many browsers and versions. Imagine attempting to maintain a web site which uses many of the browser variables available from the Ultimate Browser Sniffer.
| browser vendor | is_nav, is_ie, is_opera, is_hotjava, is_webtv, is_TVNavigator, is_AOLTV |
| browser version number | is_major (integer indicating major version number: 2, 3, 4 ...) is_minor (float indicating full version number: 2.02, 3.01, 4.04 ...) |
| browser vendor AND major version number | is_nav2, is_nav3, is_nav4, is_nav4up, is_nav6, is_nav6up, is_gecko, is_ie3, is_ie4, is_ie4up, is_ie5, is_ie5up, is_ie5_5, is_ie5_5up, is_ie6, is_ie6up, is_hotjava3, is_hotjava3up, is_opera2, is_opera3, is_opera4, is_opera5, is_opera5up |
| JavaScript version number | is_js (float indicating full JavaScript version number: 1, 1.1, 1.2 ...) |
| OS platform and version | is_win, is_win16, is_win32, is_win31, is_win95, is_winnt, is_win98, is_winme, is_win2k, is_os2, is_mac, is_mac68k, is_macppc, is_unix, is_sun, is_sun4, is_sun5, is_suni86, is_irix, is_irix5, is_irix6, is_hpux, is_hpux9, is_hpux10, is_aix, is_aix1, is_aix2, is_aix3, is_aix4, is_linux, is_sco, is_unixware, is_mpras, is_reliant, is_dec, is_sinix, is_freebsd, is_bsd, is_vms |
Detecting browsers using this level of detail is unworkable, unmaintainable and violates the basic principles of web authoring! I strongly advise everyone to avoid this trap.
If you only provide tests for specific browsers in your detection logic, your site will not be usable if a visitor uses a different browser. Consider the following example:
');
}
else if (document.layers)
{
// Navigator 4
document.write('');
}
]]>
Note how the above example only provided stylesheets for Internet Explorer and Navigator 4 and even then only if the visitor has JavaScript support turned on in their browser. Users of Netscape 6, Netscape 7, CompuServe 7, Mozilla, Opera will not be able to view the site properly.
A common mistake web authors make is to assume that if a browser is not Netscape Navigator 4, it must be Internet Explorer and vice versa. For example:
Note how the above example assumed that any browser that was not Internet Explorer was Navigator 4 and attempted to use Layers. This is a common source of problems when using browsers based upon Netscape Gecko as well as Opera. A similar error can be seen in the following example:
Netscape 6 was the first commercial browser released based upon Netscape Gecko. Due to a lack of communication and understanding, many sites have created inappropriate detection strategies based upon the Netscape 6 user agent string. Netscape 6's user agent string follows the HTTP standards for specifying the version of the user agent. (see Mozilla user-agent strings and Netscape Gecko User Agent Strings)
Mozilla/5.0 (...) Gecko/20001108 Netscape6/6.0
The first vendor/version (Mozilla/5.0)
indicates that Netscape 6 is a fifth generation browser
and is not identical to earlier browsers. All Gecko based browsers
currently report Mozilla/5.0 as their primary version
although no other browser does so at the moment. Hopefully when
other browser vendors achieve the same level of standards support
as Gecko and begin to drop support for legacy browsers, they too
will begin to report version 5. Assuming that only Netscape Gecko
will use Mozilla/5.0 will cause your browser detection
logic to fail as soon as another browser vendor releases a
browser which reports Mozilla/5.0.
The second vendor/version (Gecko/20001108) identifies
Netscape 6 as a particular release of Netscape Gecko which was
built on November 8, 2000. If you must detect Gecko using the
user agent string, Gecko/version is the most appropriate
string to search for.
The third vendor/version (Netscape6/6.0) identifies
this particular instance of a Gecko browser as Netscape 6.0.
Many sites keyed off of the existence of the string
Netscape6 in the user agent and used tests similar
to:
Note how this type of detection misses any other Gecko based
browser. Unfortunately, the Netscape 6 user agent string was
not sufficiently generalizable due to it's use of the string
Netscape6 as a description of the vendor.
Netscape 7 corrects this error and introduces another chance
for user agent string based detection to fail.
Mozilla/5.0 (...) Gecko/200207XX Netscape/7.0
Note how Netscape 7 no longer uses the string Netscape6
as the Vendor. Any user agent string detection strategy for Gecko
based upon the existence of the string Netscape6 will
fail to detect Netscape 7.
As we already discussed, a common approach in the past was to use objects to classify browsers by vendor/version. A common type of detection which originally was written to support only Netscape Navigator 4 and Internet Explorer 4 might look like:
With the introduction of the W3C DOM, the standard method
document.getElementById became available in
Internet Explorer 5 and later in Netscape 6 (Gecko). Many
web authors decided that the easiest way to add support
for Netscape Gecko was to add another code fork as follows:
The approach is incorrect since it assumes that the only other browser
besides Internet Explorer 5+ that implements document.getElementById
is Netscape Gecko. This is not true today and will become even less true
as more browsers which support the W3C DOM Standards are introduced in the future.
While the period from 1994-2000 was dominated by incompatible non-standard browsers from Netscape and Microsoft, today the dominating factor in web development are the standards proposed by the World Wide Web Consortium (W3C). Standards are important for web developers due to the increased flexibility, power of presentation, support for users with disabilities to name just a few reasons.
Targeting your web content to particular vendors ignores the possibility that other browsers which support the same standards may be introduced in the future. A common problem on the web today is the assumption that the only browsers in the world are Netscape Navigator and Microsoft Internet Explorer. This ignores the existence of Opera as well as the newer handheld devices which are being used to access the web today and in the future.
Today, both Netscape (Netscape 6 and above) and Microsoft (Internet Explorer 5.5 and above) provide browsers which due to their support for the standards are more similar than they are different. This similarity will only increase as each browser implements more and more of the standards.
Netscape 6 and above, Internet Explorer 6 on Windows, and Internet Explorer 5 for Macintosh all support DOCTYPE switching. This is a technique where these browsers can be switched from Quirks mode (which emulates buggy implementations in earlier generation browsers) to Standards mode (which more strictly adhers to the Standards). For new content, we recommend that you use a DOCTYPE which will invoke Standards mode in Netscape Gecko and Internet Explorer 6. This will ensure that your designs work similarly in these browsers as well as in any other browsers which support the Standards.
Always provide content and code paths for unknown browsers. The recommended approach is to assume that any unknown browser supports the basic standards of HTML and CSS and to a certain extent JavaScript and the W3C DOM. This will guarantee that your content will be supported today and in the future by any browser which supports the standards.
Authoring content which is standards compliant is the easiest way to support the widest range of user agents and to decrease your maintenance costs. While it is not always possible to avoid vendor/version specific differences between browsers, the use of such features and the distinction between browsers based on vendor/version should be strictly limited to those areas where it is still required.
Server side browser detection requires the use of user agent strings. We recommend that the use of user agent string based detection be limited to server side situations and except in those circumstances where it is absolutely required such as when details of the Netscape Gecko branch are required.
There are legitimate reasons to use the user
agent string (or the
navigator
object) to determine
exactly what vendor, version or operating system is being used. Many
financial sites (banks, online stock trading firms, etc) have very
strict policies with respect to what browsers they support. This is
due to the history of security exploits that have been discovered in
older browsers. If you have the need to only allow specific versions
of browsers to use your secure site, then the user agent string and
the related information from the navigator object can
be very useful.
You can also use detailed information regarding a browser's version to work around bugs in specific releases of a browser. However, this can quickly become a maintenance nightmare if you are not careful. I recommend that you only provide work arounds for bugs on a temporary basis and as soon as bugs are corrected in newer releases of the browser that you require your visitors to upgrade their browser.
No commercial web site today makes complete support for Netscape Navigator versions 1, 2 or 3 or Microsoft Internet Explorer 3 a requirement. The reasons are that the capabilities of such browsers are far too limited compared to more modern browsers, the added development and quality assurance requirements add too much to the development cost of web sites and the market share of such browsers does not justify the expense of supporting them.
One of the most important decisions you can make in order to improve the quality of your site and decrease development, maintenance and quality assurance costs is to provide only limited support for older browsers such as Netscape Navigator 4 and Internet Explorer 4. One of the more common approaches in major web sites is to provide a downlevel version of a web page to older browsers while providing a richer page which uses advanced CSS and JavaScript to more modern browsers. This can be accomplished through server side browser detection either as part of a scripted solution or as part of the web server's native ability to serve different content to different user agents. This approach does not necessarily require you to author separate pages for downlevel and modern browsers. A common solution is to author content in a neutral format such as XML and use XSLT transformations to generate the necessary HTML for each class of browser.
Whether a particular browser should be provided with downlevel content depends to an extent on what features of CSS or JavaScript are being used in the advanced content. Netscape Navigator 4 and Internet Explorer 4 should both be considered downlevel browsers for most pages due to their limited support for CSS and the more recent DOM based standards. If your pages make use of advanced JavaScript which manipulates or creates new content using the W3C DOM Core, then Opera 5 and 6 should be considered downlevel as well due to their limited support for the W3C DOM.
The future belongs to developers and browsers which support standards. If you fail to take advantage of the coming change in browsers, your competitors will eat your lunch. Once that happens, the only place your web site will be found is on the web archive.
Older browsers have many limitations which result in their ignoring more advanced features. By judiciously using these limitations in older browsers you can include modern content while at the same time supporting older browsers.
HTML provides several methods of detecting support for various features such as support for scripting and FRAMES. Use these natural abilities of HTML to extend the range of browsers your content supports.
FRAMES