Jan*_*ich 43 html javascript dom cross-browser
我将在一段时间内扮演一个魔鬼的拥护者.我一直在想为什么浏览器检测(与特征检测相反)被认为是一种不好的做法.如果我测试某个版本的某个浏览器并确认,某个功能的行为是以某种可预测的方式进行的,那么决定做特殊情况似乎没问题.原因在于它将来会万无一失,因为这部分浏览器版本不会改变.另一方面,如果我检测到DOM元素具有函数X,则不一定意味着:
我只是偷看了jQuery源代码,他们通过在DOM中插入一个精心构建的HTML片段然后检查它的特定功能来进行特征检测.这是一种明智而坚实的方式,但我会说,如果我在我的小小的个人JavaScript(没有jQuery)中做了类似的事情,那将会有点太沉重.它们还具有几乎无限的QA资源的优势.另一方面,你经常看到人们做的是他们检查函数X的存在,然后基于此,他们假设函数将在具有此函数的所有浏览器中以某种方式运行.
我没有说任何意义上的功能检测不是一件好事(如果使用得当),但我想知道为什么浏览器检测通常会立即被解雇,即使它听起来合乎逻辑.我想知道这是否是另一个时髦的事情.
Cre*_*esh 26
在我看来,自从几年前Resig 发表这篇文章以来,浏览器检测已经被广泛接受了.然而,Resig的注释特定于库/框架代码,即其他[特定于域的]应用程序/站点将使用的代码.
我认为特征检测毫无疑问非常适合库/框架.对于特定于域的应用程序,我不太确定浏览器检测是否那么糟糕.它适用于解决难以进行特征检测的已知浏览器特性,或适用于在功能本身实现中存在缺陷的浏览器.浏览器检测适当的时间:
也就是说,在进行浏览器检测时,有一些主要的缺陷(可能是我们大多数人都承诺的).
kan*_*gax 23
这是一篇很好的文章,解释了特征检测如何在浏览器嗅探方面有多种优势.
事实是,嗅探非常脆弱.它在理论上很脆弱,因为它依赖于任意 userAgent字符串,然后实际上将该字符串映射到某个行为.正如时间所示,它在实践中也很脆弱.测试几十个浏览器的每个主要版本和次要版本并试图解析其中一些版本的版本号根本不实用; 另一方面,测试怪癖的某些行为要强得多.例如,功能测试经常捕获浏览器供应商偶然相互复制的错误和不一致.
根据我自己的经验,在IE8中修复Prototype.js,我知道如果我们首先没有嗅探,可以避免90%的问题.
在修复Prototype.js时,我发现需要测试的一些功能实际上在JS库中很常见,所以我为任何愿意摆脱嗅探的人做了一些常见的功能测试.
理想的解决方案是将功能和浏览器检测结合起来.前者由于你提到的点和后者而失败,因为有时浏览器会发布虚假信息以"使事情有效".
Mozilla有一个很棒的浏览器检测入门,也可能对你有所帮助.
来自维基百科 "在其历史的各个阶段,Web的使用已被一个浏览器所主导,以至于许多网站只能用于特定的浏览器,而不是根据W3C和IETF等机构的标准.此类站点通常包含"浏览器嗅探"代码,该代码根据收到的用户代理字符串更改发送的信息.这可能意味着不太流行的浏览器不会发送复杂内容,即使他们可能能够正确处理它,或者在极端情况下拒绝所有内容.因此,各种浏览器"隐藏"或"欺骗"此字符串,以便将自己标识为此类检测代码的其他内容;通常,浏览器的真实身份随后会包含在字符串中.
| 归档时间: |
|
| 查看次数: |
26873 次 |
| 最近记录: |