|
|
特性檢測
起初前端工程師們就極力反對瀏覽器檢測，他們認為類似user-agent嗅探的方法是很不好的，理由是它并不是一種面向未來的代碼，無法適應新版的瀏覽器。更好的做法是使用特性檢測，就像這樣：
復制代碼 代碼如下:
if (navigator.userAgent.indexOf("MSIE 7") > -1){
//do something
}
而更好的做法是這樣：
復制代碼 代碼如下:
if(document.all){
//do something
}
這兩種方式并不相同。前者是檢測瀏覽器的特殊名稱和版本；后者卻是檢測瀏覽器的特性。UA嗅探能夠精確得到瀏覽器的類型和版本（至少能得知瀏覽器類型），而特性檢測卻是去確定瀏覽器是否擁有某個對象或者支持某個方法。注意這兩者是完全不同的。
因為特性檢測依賴于哪些瀏覽器支持，當出現(xiàn)新版本瀏覽器的時候需要繁瑣的確認工作。例如DOM標準剛出現(xiàn)的時候，并不是所有瀏覽器都支持getElementById()方法，所以一開始代碼可能是這樣：
復制代碼 代碼如下:
if(document.getElementById){ //DOM
element = document.getElementById(id);
} else if (document.all) { //IE
element = document.all[id];
} else if (document.layers){ //NETscape < 6
element = document.layers[id];
}
這是特性檢測很好的一個例子，亮點在于當其它瀏覽器開始支持getElementById()方法時不必修改代碼。
混合方式
后來前端工程師們考慮改進的寫法，代碼變化成這樣：
復制代碼 代碼如下:
//AVOID!!!
if (document.all) { //IE
id = document.uniqueID;
} else {
id = Math.random();
}
這個代碼的問題是通過檢測document.all屬性來確定是否是IE。當確定是IE后，假定使用私有的document.uniqueID屬性也是安全的。然而，目前所作的只是確定是否支持document.all，并非是去辨識瀏覽器是否為IE。僅僅支持document.all的話也不意味著document.uniqueID是可用的。
后來人們開始這樣寫，用下面那行代替上面的：
var isIE = navigator.userAgent.indexOf("MSIE") > -1;
//下面這行代替上面那行
var isIE = !!document.all;這些變化說明大家對“不要使用UA嗅探”存在誤解――不再對瀏覽器的詳細信息進行檢測，取而代之的是通過特性的支持來推斷。這種基于瀏覽器特性檢測的方式非常不好。
后來前端們發(fā)現(xiàn)document.all并不可靠，更好的檢測IE變?yōu)椋?
var isIE = !!document.all && document.uniqueID;這種實現(xiàn)方式陷入歧途。不僅需要費時費事地去識別瀏覽器所增加的特性支持，另外也不能確定其它瀏覽器開始支持相同的特性。
如果你認為這樣的代碼并未被廣泛使用，那么看看來自于老版本的Mootools代碼片段吧：
復制代碼 代碼如下:
//from MooTools 1.1.2
if (window.ActiveXObject) window.ie = window[window.XMLHttpRequest ? 'ie7' : 'ie6'] = true;
else if (document.childNodes && !document.all && !navigator.taintEnabled) window.webkit = window[window.xpath ? 'webkit420' : 'webkit419'] = true;
else if (document.getBoxObjectFor != null || window.mozInnerScreenX != null) window.gecko = true;
注意它是如何使用特性檢測的。我可以指出它一系列的問題，比如通過檢測window.ie會將ie8誤認為ie7。
余波
隨著瀏覽器的快速發(fā)展，使用特性檢測變得越來越困難和不可靠。但是Mootools 1.2.4仍然使用這一方法，例如：getBoxObjectFor()。
復制代碼 代碼如下:
//from MooTools 1.2.4
var Browser = $merge({
Engine: {name: 'unknown', version: 0},
Platform: {name: (window.orientation != undefined) ? 'ipod' : (navigator.platform.match(/mac|win|linux/i) || ['other'])[0].toLowerCase()},
Features: {xpath: !!(document.evaluate), air: !!(window.runtime), query: !!(document.querySelector)},
Plugins: {},
Engines: {
presto: function(){
return (!window.opera) ? false : ((arguments.callee.caller) ? 960 : ((document.getElementsByClassName) ? 950 : 925));
},
trident: function(){
return (!window.ActiveXObject) ? false : ((window.XMLHttpRequest) ? ((document.querySelectorAll) ? 6 : 5) : 4);
},
webkit: function(){
return (navigator.taintEnabled) ? false : ((Browser.Features.xpath) ? ((Browser.Features.query) ? 525 : 420) : 419);
},
gecko: function(){
return (!document.getBoxObjectFor && window.mozInnerScreenX == null) ? false : ((document.getElementsByClassName) ? 19 : 18);
}
}
}, Browser || {});
應該怎么做？
特性檢測是個應該避免的方法，盡管直接進行特性檢測是個很好的方法，并且大部分情況下能滿足需求。一般只要在檢測前知道這個特性是否被實現(xiàn)即可，而不會去考慮它們之間的關系。
我并非是說永遠不使用瀏覽器特性檢測而是基于UA嗅探，因為我相信它還是有很多用途的，然而我不相信它有很多合理的用途。如果你考慮UA嗅探的話，請先貫徹這一思想：唯一安全的方式是針對特定瀏覽器的特定版本，超出范圍之外都是不可靠的――例如新出的瀏覽器版本。其實這樣做也是個明智的辦法，因為相較于向前兼容不確定的新版本而言，向后兼容老版本是最簡單的做法。
JavaScript技術(shù)：javascript 特性檢測并非瀏覽器檢測，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
