渐进增强的Web设计——1.1　测试浏览器能力

在高级CSS、客户端JavaScript和Ajax，以及Flash等浏览器插件的支持下，最新的网页技术创新赋予了现代网站视觉吸引力和丰富的交互能力。不过它们有很大的局限性：浏览器和设备对这些技术的支持程度参差不齐。虽然现代浏览器和最新的移动设备有能力渲染出非常复杂的界面，但它们所占的比例还不够大。正如引言中谈到的那样，制作一个只适用于少数高端浏览器和设备的网站或应用程序很难服务于最广大的用户。 我们想要确保客户的内容、消息和功能可以到达每一个人，不仅是那些使用现代浏览器（支持最新网页技术）的人，而是任何有可上网设备的用户。因此，我们在几年前开始将渐进增强的理念引入客户的项目中。 渐进增强的原理很简单：输出符合标准的纯HTML页面，使所有设备都更有可能渲染出可用的内容。然后，只为那些能理解CSS和JavaScript的浏览器在页面上无缝叠加增强的样式和脚本。 不过，开始用这种方法构建网站并测试结果时，我们有了一个重大发现：这种方法没有考虑到许多旧版浏览器和较新的移动浏览器仅部分支持JavaScript和CSS。此外，用户还可能会基于速度、安全或可用性等原因有意禁用这些技术。在现实世界里，CSS和JavaScript必须协同工作才能实现复杂的应用程序界面和组件。（在启用JavaScript但不能正常支持CSS定位的浏览器中，日历组件或滑块肯定不能用。） 在对基于渐进增强的网站进行测试时，我们发现不少浏览器会把一个本来可用的HTML页面“增强”为一团“乱麻”。原因就是这些浏览器并不完全支持它们运行的脚本和应用的样式。然而，我们如何知道哪些浏览器有能力正确渲染出这些增强信息呢？ 我们意识到，要实现渐进增强方法，让每个人都有可用体验的目标，需要做三件事。 仔细检查设计，确保每一部分（即使是最新潮的Web 2.0或Ajax组件）都是基于结构清晰的语义化HTML，在任何完全不支持CSS或JavaScript的浏览器上，都能提供功能完整的基本体验。 在添加增强信息之前，先测试某种浏览器的CSS和JavaScript支持程度，以更好判断是为它提供基本体验，还是应该进行增强。 对那些已升级到增强体验的浏览器，要确保花大力气维护可访问性，比如提供键盘导航支持和添加支持屏幕阅读器的功能。 本章将讨论为确定哪些浏览器应该获得增强体验而开发的浏览器能力测试模型，以及它可以测试哪些功能。然后将介绍我们在日常客户项目中使用的渐进增强方法，这个方法的第一步叫做“X光透视”。这一步会分析某种复杂的界面设计，拟出能支持基本功能体验的语义化HTML，然后制订计划，为有能力的浏览器开发高级CSS和JavaScript，以创造增强体验，同时保持对屏幕阅读器的完整可访问性。 1.1　测试浏览器能力 我们对渐进增强的初始研究揭示出大多数开发者选择的页面增强方式是以下两者之一：向所有启用JavaScript的浏览器传递增强信息，或通过浏览器嗅探（检测Internet Explorer等特定用户代理或WebKit这样的渲染引擎）仅对特定的一组浏览器输出增强信息。 我们从一开始就排除了浏览器嗅探，原因有下面几点。 有效的嗅探需要精确了解每种浏览器的行为（以及其各个版本的变化情况），这使维护脚本成为一项巨大、复杂和永无止境的挑战。 根据定义，它不是向后兼容的。你只能嗅探当前存在的浏览器，如果某种能提供增强体验的新款浏览器明天发布，它就会被拒之门外，除非把它们加入列表。 即使是最详尽的用户代理白名单也可能会失效，因为浏览器可以被配置成报告错误的用户代理信息，从而绕过这些技术（也被称作浏览器欺骗）。 所以第一种方式（向所有启用JavaScript的浏览器传递增强信息）看上去是更好的选择，因为大多数支持JavaScript的浏览器都能够渲染出增强的体验。但是前面提到，某些浏览器只是部分支持这些增强信息，从而导致布局混乱和JavaScript错误，这种情况的数量多得惊人。 观察这些情况时，我们注意到这些缺损的体验植根于两大模式：一些浏览器错误地渲染了CSS，原因是它们不能很好地支持盒模型（box model）、定位、浮动或其他源于网页标准的常见CSS属性；另一些则不能很好地运行常见JavaScript功能，例如DOM操作、事件处理、调整窗口大小和执行Ajax请求。 如果我们有一种可靠的方法能检验若干有恰当代表性的浏览器能力，然后仅在我们对CSS和JavaScript能正确协同工作有十足把握时才输出增强信息，那么应用我们的渐进增强方法就会容易和可靠得多。 带着这个目标，我们通过不断试错开发出了浏览器能力测试框架。其中的JavaScript基本检验项目相当简单：我们的测试使用了一种叫做对象探测（object detection）的方法，通过它实际上能询问浏览器是否识别如document.getElementById函数这样的本地对象，并得到明确的true或false回应。每项测试都以一种容错和非干扰性的方式编写，因此如果某种浏览器不理解一个JavaScript方法，它不会报错。 更具挑战性的问题是如何判断某种浏览器是否能正确支持高级CSS技术。没有任何原生方法能使用对象探测来询问某种浏览器是否能恰当渲染具体的CSS特性，例如浮动、定位、垂直分层元素或透明度。 因此，我们设计了一套CSS能力测试用例专门做这件事。每一项CSS测试都使用JavaScript，将不可见的HTML元素插入到网页中，应用一组特定的高级CSS规则，然后运行一个JavaScript函数来测量结果。举个例子，要了解浏览器是否正确支持定位，测试会使用CSS将一个div放置在某个特定位置，然后运行一个JavaScript函数来比较测出的坐标是否与参照条件匹配。 一种浏览器通过全套能力测试后，我们就可以很有把握地认定它对CSS和JavaScript两者的处理都是一致并且符合标准的，应该能够良好地渲染出增强体验。到这一步，测试会动态加载高级样式表和脚本，将基本的HTML标记转变成增强体验，并在页面中添加一个链接以供那些偏爱简单版本的用户关闭增强体验。最后，测试会设置一个cookie防止之后再次运行能力测试，从而提升页面速度。 将测试框架实际投入使用时，我们见到了它为渐进增强项目带来的实际益处。首先，它给了我们一种非常可靠的方式来划分哪些浏览器可以正确显示增强体验，哪些不能，因此可以大幅降低本来可用的基本页面被增强信息损坏的危险。又因为这个测试只会在那些通过的浏览器上加载增强版CSS和JavaScript文件，所以它让我们能提供小得多的、更加流线化的基本体验（不会预先载入大量标记、样式或脚本），结果是下载时间大大加快，不必要的服务器请求也变少了。 这个测试框架的设计是高度灵活和模块化的，可以自定义修改，以测试具体客户项目要求的特定CSS和JavaScript能力。如果不存在复杂的CSS浮动或Ajax脚本，我们就可以从测试标准里移除相应的代码。 在我们的项目中，通常会运行一套能力测试，简单地将浏览器划分成“基本”或“增强”两个组，以方便编程和维护。我们将这种对基本和增强的区分视作以最小的力气为最广泛的设备提供访问的方式。从这种基准支持程度开始，你就可以相当容易地进一步定制测试脚本，将浏览器更加精细地划分成多个能力等级或为特定设备（比如iPhone或Kindle）提供优化过的体验。 第6章将详细分析这个能力测试的结构和运行机制，并讨论一些能体现模块化方式优点的情况。