当我们谈论浏览器兼容性时,大多数时候我们将其定义为应用程序将支持的最低版本的浏览器列表。例如: -应该处理浏览器兼容性问题吗?
IE9 +,Firefox的25 +,Chrome浏览器32+等
当测试兼容性,我们一般测试基线和最新版本。 如果我们想使它更广泛,我们可以使用诸如SauceLabs之类的工具来测试它们之间的所有版本。
我的问题不是关于我们是否可以测试兼容性,而是应该如何或应该如何考虑应支持哪个版本的浏览器。
例如,我遇到了aurelia-polyfills
的问题。
该库无法加载到Firefox 35中的行(function(o, s) { ... }(Object, Symbol))
与Symbol is not defined
。
此代码在Firefox 29和最新版本(54)中正常工作。我不知道35之前和之后有多少版本会遇到这个问题。
这个问题,国际海事组织,有更多的火狐浏览器和更少的库,因为它应该取消Symbol
为undefined
并让代码检查并正确处理它。这与IE不能正确处理enum
等关键字的问题类似。
现在,问题是,如果这被认为是图书馆的错误,或者图书馆应该声明这个中间版本的Firefox不被支持?
一方面,排除这个版本是有意义的,因为它是浏览器的“错误做法”。图书馆作者无法对浏览器产生的任何和所有问题进行殴打。特别是现在,与过去相比,新版本的浏览器更为频繁。一些错误将会发生。
另一方面,这恰恰是“浏览器兼容性”的意义所在,应予以处理。图书馆作者不能忽视它们,因为它们被用户使用。但在这种特殊情况下,它不会工作,因为每当访问Symbol
都会使系统崩溃。
另一点是,当浏览器兼容性表更新时,它会“转移”到出现问题的那些版本。
这意味着要么将兼容性表从“IE9 +,Firefox 25+,...”更新为“IE10 +,Firefox 35 +,...”和“WTF”,要么强制使用更窄的表格。 “IE10 +,Firefox 52 +,...”。
我认为我们不得不硬着头皮,继续支持“所有最新版本”,或者在兼容性表中留下一些漏洞,只支持“黄金版”。
你会推荐什么?
顺便说一句,我没有任何反对Firefox,只用它作为例子。
优秀的答案。非常感谢! – unional