浏览器检测与特征检测

Question

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

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

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

我并不是说特征检测不是一件好事（如果使用得当的话），但我想知道为什么即使听起来合乎逻辑，浏览器检测通常也会立即被忽略。我想知道这是否是另一种流行的说法。

Answer 1

在我看来，自几年前 Resig 的this post 以来，浏览器检测一直受到广泛反对。然而，Resig 的 cmets 特定于库/框架代码，即将由其他 [域特定] 应用程序/站点使用的代码。

我认为特征检测毫无疑问非常适合库/框架。但是，对于特定于域的应用程序，我不太确定浏览器检测是否那么糟糕。它适用于解决难以检测到的已知浏览器特性，或者适用于在实现特性本身时存在错误的浏览器。适合浏览器检测的时间：

• 不是跨浏览器并且需要显示针对该客户端浏览器定制的警告/对话框/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 以供任何愿意摆脱嗅探的人使用。

Answer 3

理想的解决方案是结合功能和浏览器检测。前者因为你提到的几点而失败，后者因为有时浏览器会发布虚假信息以“让事情正常运行”。

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

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