9.1 能力检测
最常用也最为人们广泛接受的客户端检测形式是能力检测(又称特性检测)。能力检测的目标不是识别特定的浏览器,而是识别浏览器的能力。采用这种方式不必顾及特定的浏览器如何如何,只要确定浏览器支持特定的能力,就可以给出解决方案。能力检测的基本模式如下:
if (object.propertyInQuestion){ //使用object.propertyInQuestion }
举例来说,IE5.0 之前的版本不支持document.getElementById()这个DOM 方法。尽管可以使用非标准的document.all 属性实现相同的目的,但IE 的早期版本中确实不存在document.get-ElementById()。于是,也就有了类似下面的能力检测代码:
function getElement(id) { if (document.getElementById) {return document.getElementById(id); } else if (document.all) {return document.all[id]; } else {throw new Error("No way to retrieve element!"); } }
这里的getElement()函数的用途是返回具有给定ID 的元素。因为document.getElementById()是实现这一目的的标准方式,所以一开始就测试了这个方法。如果该函数存在(不是未定义),则使用该函数。否则,就要继续检测document.all 是否存在,如果是,则使用它。如果上述两个特性都不存在(很有可能),则创建并抛出错误,表示这个函数无法使用。
要理解能力检测,首先必须理解两个重要的概念。如前所述,第一个概念就是先检测达成目的的最常用的特性。对前面的例子来说,就是要先检测document.getElementById(),后检测document.all.
先检测最常用的特性可以保证代码最优化,因为在多数情况下都可以避免测试多个条件。第二个重要的概念就是必须测试实际要用到的特性。一个特性存在,不一定意味着另一个特性也存在。来看一个例子:
function getWindowWidth() { if (document.all) { //假设是IEreturn document.documentElement.clientWidth; //错误的用法!!! } else {return window.innerWidth; } }
这是一个错误使用能力检测的例子。getWindowWidth()函数首先检查document.all 是否存在,如果是则返回document.documentElement.clientWidth。第8 章曾经讨论过,IE8 及之前版本确实不支持window.innerWidth 属性。但问题是document.all 存在也不一定表示浏览器就是IE。实际上,也可能是Opera;Opera 支持document.all,也支持window.innerWidth。
9.1.1 更可靠的能力检测
能力检测对于想知道某个特性是否会按照适当方式行事(而不仅仅是某个特性存在)非常有用。上一节中的例子利用类型转换来确定某个对象成员是否存在,但这样你还是不知道该成员是不是你想要的。来看下面的函数,它用来确定一个对象是否支持排序。
//不要这样做!这不是能力检测——只检测了是否存在相应的方法 function isSortable(object) { return !! object.sort; }
这个函数通过检测对象是否存在sort()方法,来确定对象是否支持排序。问题是,任何包含sort属性的对象也会返回true。
var result = isSortable({ sort: true });
检测某个属性是否存在并不能确定对象是否支持排序。更好的方式是检测sort 是不是一个函数。
//这样更好:检查sort 是不是函数 function isSortable(object){ return typeof object.sort == "function"; }
这里的typeof 操作符用于确定sort 的确是一个函数,因此可以调用它对数据进行排序。
在可能的情况下,要尽量使用typeof 进行能力检测。特别是,宿主对象没有义务让typeof 返回合理的值。最令人发指的事儿就发生在IE 中。大多数浏览器在检测到document.createElement()存在时,都会返回true。
//在IE8 及之前版本中不行 function hasCreateElement(){ return typeof document.createElement == "function"; }
在IE8 及之前版本中,这个函数返回false,因为typeof document.createElement 返回的是"object",而不是"function"。如前所述,DOM对象是宿主对象,IE 及更早版本中的宿主对象是通过COM 而非JScript 实现的。因此,document.createElement()函数确实是一个COM 对象,所以typeof 才会返回"object"。IE9 纠正了这个问题,对所有DOM 方法都返回"function"。
关于typeof 的行为不标准,IE 中还可以举出例子来。ActiveX 对象(只有IE 支持)与其他对象的行为差异很大。例如,不使用typeof 测试某个属性会导致错误,如下所示。
//在IE 中会导致错误 var xhr = new ActiveXObject("Microsoft.XMLHttp"); if (xhr.open){ //这里会发生错误 //执行操作 }
像这样直接把函数作为属性访问会导致JavaScript 错误。使用typeof 操作符会更靠谱一点,但IE对typeof xhr.open 会返回"unknown"。这就意味着,在浏览器环境下测试任何对象的某个特性是否存在,要使用下面这个函数。
//作者:Peter Michaux function isHostMethod(object, property) { var t = typeof object[property]; return t == 'function' || ( !! (t == 'object' && object[property])) || t == 'unknown'; }
可以像下面这样使用这个函数:
result = isHostMethod(xhr, "open"); //true result = isHostMethod(xhr, "foo"); //false
目前使用isHostMethod()方法还是比较可靠的,因为它考虑到了浏览器的怪异行为。不过也要注意,宿主对象没有义务保持目前的实现方式不变,也不一定会模仿已有宿主对象的行为。所以,这个函数——以及其他类似函数,都不能百分之百地保证永远可靠。作为开发人员,必须对自己要使用某个功能的风险作出理性的估计。
要想深入了解围绕JavaScript 中能力检测的一些观点,请参考Peter Michaux 的文章“Feature Detection: State of the Art Browser Scripting”,网址为http://peter.michaux.ca/articles/feature-detection-state-of-the-art-browser-scripting。
9.1.2 能力检测,不是浏览器检测
检测某个或某几个特性并不能够确定浏览器。下面给出的这段代码(或与之差不多的代码)可以在许多网站中看到,这种“浏览器检测”代码就是错误地依赖能力检测的典型示例。
//错误!还不够具体 var isFirefox = !!(navigator.vendor && navigator.vendorSub); //错误!假设过头了 var isIE = !!(document.all && document.uniqueID);
这两行代码代表了对能力检测的典型误用。以前,确实可以通过检测navigator.vendor 和navigator.vendorSub 来确定Firefox 浏览器。但是,Safari 也依葫芦画瓢地实现了相同的属性。于是,这段代码就会导致人们作出错误的判断。为检测IE,代码测试了document.all 和document.uniqueID。这就相当于假设IE 将来的版本中仍然会继续存在这两个属性,同时还假设其他浏览器都不会实现这两个属性。最后,这两个检测都使用了双逻辑非操作符来得到布尔值(比先存储后访问的效果更好)。
实际上,根据浏览器不同将能力组合起来是更可取的方式。如果你知道自己的应用程序需要使用某些特定的浏览器特性,那么最好是一次性检测所有相关特性,而不要分别检测。看下面的例子。
//确定浏览器是否支持Netscape 风格的插件 var hasNSPlugins = !!(navigator.plugins && navigator.plugins.length); //确定浏览器是否具有DOM1 级规定的能力 var hasDOM1 = !!(document.getElementById && document.createElement && document.getElementsByTagName);
以上例子展示了两个检测:一个检测浏览器是否支持Netscapte 风格的插件;另一个检测浏览器是否具备DOM1 级所规定的能力。得到的布尔值可以在以后继续使用,从而节省重新检测能力的时间。
在实际开发中,应该将能力检测作为确定下一步解决方案的依据,而不是用它来判断用户使用的是什么浏览器。