浏览器检测与特征检测

Question

我将暂时扮演一个魔鬼的拥护者。我一直在想为什么浏览器检测（与特征检测相反）被认为是一种不好的做法。如果我测试某个版本的某个浏览器并确认，某个功能的行为是以某种可预测的方式进行的，那么决定做特殊情况似乎没问题。原因在于它将来会万无一失，因为这部分浏览器版本不会改变。另一方面，如果我检测到DOM元素具有函数X，则不一定意味着：

1. 此功能在所有浏览器中的工作方式相同，
2. 更重要的是，即使在将来的所有浏览器中它都会以相同的方式工作。

我只是偷看了jQuery源代码，他们通过将精心构建的HTML片段插入DOM中进行特征检测，然后检查它是否具有某些功能。这是一种明智而坚实的方式，但我会说，如果我在我的小小的个人JavaScript（没有jQuery）中做了类似的事情，那将会有点太沉重。它们还具有几乎无限的QA资源的优势。另一方面，你经常看到人们做的是检查函数X是否存在，然后基于此，他们假设函数在所有具有此函数的浏览器中都会以某种方式运行。

我没有说任何意义上的功能检测不是一件好事（如果使用得当），但我想知道为什么浏览器检测通常会立即被解雇，即使它听起来合乎逻辑。我想知道这是否是另一个时髦的事情。

Answer 1

在我看来，自从几年前Resig this post以来，浏览器检测已经被人们广泛接受了。然而，Resig的评论特定于库/框架代码，即其他[特定于域]的应用程序/站点将消费的代码。

我认为功能检测毫无疑问是适合库/框架的 。对于特定于域的应用程序，我不太确定浏览器检测是否那么糟糕。它适用于解决难以进行特征检测的已知浏览器特性，或适用于在功能本身实现中存在缺陷的浏览器。浏览器检测适当的时间：

• 不是跨浏览器的网站/应用程序，需要向该客户端的浏览器显示警告/对话框/ DifferentPage。这在遗留应用程序中很常见。
• 对支持哪些浏览器和版本的严格政策的银行或私人网站（以避免可能危及用户数据的已知安全漏洞）
• 微优化：在以某种方式执行某些操作时，偶尔会有一个浏览器比其他浏览器快得多。根据您的用户群，在特定浏览器/版本上进行分支可能是有利的。
• IE6中缺乏png透明度
• 许多显示/呈现问题（阅读：IE css支持）仅在特定浏览器版本中见证，而您实际上并不知道要测试的功能。

也就是说，在进行浏览器检测时，有一些major pitfalls（可能由我们大多数人承诺）。

Answer 2

Here's a good article解释了特征检测如何在浏览器嗅探方面的优势。

事实上，嗅探非常脆弱。它在理论上很脆弱，因为它依赖于任意 userAgent字符串，然后实际上将该字符串映射到某个行为。正如时间所示，它在实践中也很脆弱。测试几十个浏览器的每个主要版本和次要版本并试图解析其中一些版本的版本号根本不实用;另一方面，测试怪癖的某些行为要强得多。例如，功能测试经常捕获浏览器供应商偶然相互复制的错误和不一致。

根据我自己的经验，在IE8中修复Prototype.js，我知道如果我们不首先嗅探，可以避免90％的问题。

在修复Prototype.js时，我发现需要测试的一些功能实际上在JS库中很常见，所以我为那些愿意摆脱嗅探的人制作了一些common feature tests的集合。 / p>

Answer 3

理想的解决方案是将功能和浏览器检测结合起来。前者由于你提到的点和后者而失败，因为有时浏览器会发布虚假信息以“让事情变得有效”。

Mozilla有一个很棒的Browser Detection Primer也可能对您有所帮助。

来自wikipedia “在其历史的不同阶段，网络的使用一直由一个浏览器主导，以至于许多网站只能用于特定的浏览器，而不是根据W3C和IETF等机构的标准。通常包括“浏览器嗅探”代码，它根据收到的用户代理字符串改变发送的信息。这可能意味着不太流行的浏览器不会发送复杂的内容，即使他们可能能够正确处理它，或者极端情况拒绝了所有内容。因此，各种浏览器“隐藏”或“欺骗”此字符串，以便将自己标识为此类检测代码的其他内容;通常，浏览器的真实身份随后会包含在字符串中。“