Web标准有效缩减维护时间及Web站点的外观和功能比较_Web标准教程
教程Tag：暂无Tag,欢迎添加,赚取U币!
对您的 Web 页面进行简单更改是否仍需要花费很长时间？您是否由于 Web 页面的大小而支付了过高的带宽费用？您是否曾仅为了处理浏览器差别而编写几百行代码？假如是这样，那么您可能过多地强调了 Web 页面的外观，而不是其功能。并且，您也可能花费了过多的时间来确保对旧浏览器的向后兼容性。
本文是质量因素 系列文章之一，将向您展示如何转移 Web 站点的重点和优先级 [并使用 W3C 标准，如XHTML、级联样式表（CSS）和文档对象模型（DOM）] 来减少维护时间、宽带费用以及所编写的特定于浏览器的代码量。
维护梦魇
SHEEP Web 小组被指派去增强 SHEEP 客户销售应用程序 —— 一个典型的电子商务站点，此站点主要包含产品目录和购物车。该小组注重到的第一件事情是这个站点非常有吸引力。它以生动有趣的方式来展示公司的产品。但是用户满足度调查却反复表明用户对于大量的产品描述和产品细节以及对产品进行比较的能力都不满足。
Web 小组的任务是向该商务站点添加更多内容，并增加产品比较功能。在小组进行修改时，他们至少碰到了两个主要的难题：
代码是和表及小的间隔图片一起装入的，目的是得到所需布局。当添加新行或列来显示新的内容时，很轻易出现排版错误。在很多浏览器上对每个更改进行测试后，该小组才发现了此类错误。复杂的表布局还增加了确定在何处做更改或添加内容所需的时间。
应用程序有几百行 JavaScript 代码专门用来补偿浏览器差异和非凡效果。遗憾的是，对该代码进行的最后一次维护是在引入流行的浏览器（例如 Firefox?）之前。结果，小组投入了大量的时间来修改 JavaScript 代码，以便应对较新的浏览器。
重新考虑优先级
鉴于目前所面临的问题，SHEEP 小组的架构师告知项目经理该站点的代码很难进行修改，并且该项目所需时间将远远超出当初所估计的。出于好奇，项目经理查看了 Web 站点的历史，以便查明是否有非凡原因导致该站点难于进行维护。结果表明影响该站点的两个主要因素是兼容性和外观。
该站点的第一个决定因素是对旧浏览器的向后兼容性。该站点是在 Web 早期发布的。随着站点的发展以及 Web 技术的提高，公司添加了新功能。为了确保受众尽可能地大，该站点被设计为可用于当时所有的流行浏览器。为了将浏览器市场快速变化的影响降至最低，公司决定将站点的 HTML 标记锁定在通常会被 Microsoft? Internet Explorer? 5 和 Netscape? 4 所支持的层面上。正是这个层面的兼容性导致了页面布局中额外的复杂性，并且需要使用 JavaScript 代码来添加新功能。
第二个决定因素是页面外观在不同浏览器中的一致性。页面经过了精心布置，因此无论是在 Internet Explorer、Netscape、 Opera 还是其他图形化浏览器中进行显示时，页面的外观几乎是相同的。为了实现这个目的，页面使用了大量嵌套的表和小的间隔图片，用来强制表单元格宽度。
带着这项调查结果，项目经理找到了站点主办方，然后问道：“假如只有不到 0.5% 的用户使用这些旧浏览器，那么这种兼容性是必需的吗？并且，假如可以用其他方式来树立品牌形象，那么不同浏览器中的相同外观是必需的吗？”
迁移到 Web 标准
销售应用程序示例说明了由不适当的侧重点所引起的质量问题，比如为了支持旧浏览器版本所增加的维护时间，以及为了包含特定于浏览器的标记和代码的大型 Web 页面所增加的带宽开销。幸运的是，假如使用万维网联盟（W3C）Web 标准，就能够很轻易地解决此类问题。
在 2003 年之前，Web 页设计的复杂性是由于缺少标准的或一致的 HTML 实现而导致的。浏览器通过添加对 HTML 语言的扩展来相互竞争。它们对 JavaScript 代码和文档对象模型（DOM）的支持情况也各有不同。因此，开发人员不得不创建方法以确保 Web 页面在不同浏览器中的外观是相同的。所用的技术包括使用表格对图片文本进行像素级定位、特定于浏览器的客户机和服务器代码、利用了浏览器代码中的特性或 bug 的编程等。
2003 年左右，开始出现标准的融合和支持这些标准的浏览器。1998 年开始，W3C 发布了 Web 标准以便提供规范和准则，使开发人员与浏览器实现能够相互协调。很多浏览器（例如 Netscape 4 和 Internet Explorer 5）开始实行部分 W3C Web 标准。但是，直到 2003 年，随着 Mozilla?、Netscape 6、Internet Explorer 6、Opera 7 和 Firefox 的发布，浏览器的兼容程度才达到现在的水平。虽然这些浏览器中没有一个是完全支持 W3C 标准的，但每一个又都非常接近标准，从而使开发人员可以基于主要的标准来编写代码，而不是基于特定于浏览器的实现。
现在所使用的 Web 标准致力于 Web 页面的三个方面：结构、表现形式和行为。新的准则和法律要求也触及了质量方面的问题，即可访问性。我将在下面各节中讨论这些内容。
结构：XHTML
HTML 是最初的 Web 页面标记语言。现在的 Web 标准中，HTML 已经由 XHTML 代替。随着 XML 被广泛采纳，W3C 将 HTML 重构为与 XML 兼容。得到的结果是基于 HTML 4.0 的 XHTML 1.0。使用 XHTML 的一个优点在于支持 HTML 文档的旧浏览器可以读取并正确处理 XHTML 文档。此外，由于 XHTML 是与 XML 兼容的，所以 XHTML 文档不能出现缺失的标记或不正确关闭的元素 —— 而这正是很多 HTML 文档中普遍存在的一个问题。
XHTML 的 Web 标准为 Web 页面标记语言定义了新的使命。在 XHTML 中，标记语言将仅传递内容和结构 —— 标题、段落、编号列表和定义列表等。而表现形式则更改为 CSS。从对 HTML <FONT> 标记及其他基于表现形式的标记的反对中就可以看出这种转变。
表现形式：CSS
W3C Web 标准定义了两级级联样式表（CSS）标准 —— CSS1 和 CSS2。撰写本文时，CSS3 标准还在开发中。CSS 标准定义了表示语言，用于指定 Web 页面的格式 —— 版式、布置、布局和颜色等。
CSS 答应站点的设计人员将表现形式和格式的具体说明放置在独立于 Web 页面 XHTML 文档的单独文档中。这样将答应重新使用，并且减少了必须随每个 Web 页面下载的文本数量。大多数与标准兼容的浏览器都提供了一定程度的对 CSS 文档的缓存支持。这也提供了灵活性，对一个文档进行更改不会影响另一个文档。例如，假如一些 Web 页面共享相同的 CSS 文档，则对该 CSS 文档所作的更改将反映在使用该样式表的所有页面上。
行为：ECMAScript 和 DOM
Web 标准关注的第三个方面是行为，使用 DOM 和 ECMAScript 指定。文档对象模型 (DOM) 指定了 Web 页面的表示方法和相关的浏览器对象，因此可以通过 ECMAScript 程序进行访问和操作。ECMAScript 是 JavaScript 语言的标准化版本，减少了旧浏览器脚本语言（例如 Netscape 的 JavaScript 和 Microsoft 的 Jscript）的不兼容性。使用 DOM 和 ECMAScript，Web 开发人员可以添加高级行为和操作，改善用户的 Web 体验。例如，您可以在浏览器（而不是服务器）的 Web 表单上执行字段验证。
可访问性：WAI 和 Section 508
Web 页面的质量方面也通过一套准则和规定进行了标准化。W3C 建立了一套准则，利用 Web Accessibility Initiative（WAI）来改善 Web 站点的可访问性。美国政府通过 US Code 的 Section 508 建立了用于 Web 站点可访问性的一套规定。其他很多国家也在相应的法律中考虑了类似的可访问性规定和准则。
可访问性准则的目的在于确保残疾人可以使用 Web 页面。设计可访问页面的一个有趣的副作用是它更适用于移动设备（例如 PDA、移动电话等）。
宽松的外观要求
除了向后兼容性要求外，SHEEP 小组的架构师注重到该站点陷入了这样的困境即过多使用代码来加强其在不同浏览器中的外观。这是引起问题的 Web 站点设计的诸多旧思路之一。
出于多种原因，早期的 Web 设计人员和站点主办方坚持认为其站点在所有浏览器中的外观应该是相同的。这种主张超出了对相似外观和页面可读性的要求。它要求在每个浏览器的每个页面上，都具有相同像素定位的元素和相同的字体大小。开发人员将大量时间花费在装饰 Web 页面上以确保相同的外观。
现在您应该探究一下其原因。Web 站点在不同浏览器中具有相同像素的外观有什么优势？
用户从相同的外观得到好处了吗？并非如此。大多数用户只使用单一的浏览器，因此他们仅采用一种方式来查看站点。他们并不在意站点在其他浏览器中的外观。
相同的外观能更好地维护公司的品牌形象吗？不见得。公司的品牌是通过样式、颜色、所使用的商标和徽标以及表现形式来共同建立的。公司经常改变其商标或徽标的外观以适应产品的需要。例如，大家熟知的 IBM 徽标就有各种形式 —— 单色八条线、单色十三条线、三色八条线（如很多 Thinkpad 上所示）、图标符号（眼睛和蜜蜂图标）等等。
在各浏览器中获得接近一致的外观就足够了。使用 W3C Web 标准的一个优势在于与标准兼容的浏览器将以相当一致的方式来显示页面。使用这些标准，能够以最少数量的编码获得最为接近的外观，因此，可以大大减少需要维护的代码数量。
Web 标准的好处
由于篇幅所限，不能具体演示 SHEEP 小组使用 W3C Web 标准来重构该销售网站的所有必需操作。可以在 参考资料 中找到一些关于 Web 标准迁移的文章和书籍。只考虑 Web 站点的质量方面，迁移到 Web 标准和放宽对站点外观的要求将得到至少三个方面的改良，如下所述。
易于维护
清单 1 是一个基于表的导航菜单的简化的 HTML 示例。
清单 1. 基于表的导航菜单的简单 HTML
现在看一下 清单 2，它演示了采用 XHTML 编写的相同导航菜单，并将表现形式移入独立的 CSS 文档（我没有展示 CSS）。
清单 2. 采用 XHTML Web 标准的导航菜单
显然，采用 Web 标准的版本包含更少的代码。还注重到，使用 XHTML 将减少对大块语句进行复制-粘贴编辑时所引起的问题，例如复制整个 <td></td> 子句。
Web 标准对使用了模板（由应用程序处理的 HTML 片断，用于构建发送给浏览器的最终的 HTML）的应用程序肯定有好处。当 HTML 语句分散于多个模板片断时，较简单的语句使您不会再忘记更改模板。
降低带宽开销
清单 1 和 清单 2 展示了 Web 标准解决方案中的文本更少。下面所列的参考资料表明，将传统的 HTML 迁移到 Web 标准实现后，Web 大小和所传输的字节减少了 50% 到 60%。减少的原因是：
假定某公司使用主机服务，该站点每月每 1 GB 传输量需支付 1 美元。使用传统的 Web 页面编码，该公司每月的传输量是 100 GB，则每月应支付 100 美元。迁移到 Web 标准后，该公司的 Web 站点大小减小了 50%。对于相同用户流量，该公司每月仅有 50 GB 的传输量，即节省了 50 美元。
没有用户被拒之门外
迁移到 Web 标准的另一个好处是，消除了依靠于浏览器的代码及用户阻塞。现在一些 Web 站点仍只支持单一的浏览器，通常是 Internet Explorer。糟糕的是，这些站点阻挡了 10% 到 20% 的潜在用户。
使用 Web 标准进行编码的站点可以在旧浏览器和新浏览器中进行浏览。只是在旧浏览器中，站点看起来不够漂亮 —— 更像是 90 年代的早期的基于文本的站点 —— 但内容是可用的、可读的、可访问的。让想使用站点的任何用户都可以访问站点会很有益处，非凡是对于那些提供产品销售的电子商务站点（这一点就更重要了）！
结束语
通过利用 Web 标准以及放宽某些外观要求来改进 Web 站点，可以大大缩减维护时间、增强时间和带宽使用。在兼容 Web 标准的站点中，传递到浏览器的数据量更少，因而带宽占用也更少。新式站点还将表现形式与页面内容分离开来，通过减少与内容传递相关联的操作来简化服务器编程。使用 Web 标准（如 DOM 和 ECMAScript）将减少您必须编写和维护的特定于浏览器的代码数量。并且，寻求不同浏览器间的足够接近的外观而不是完全相同的外观有助于简化 Web 站点的格式复杂性。
作为 Web 站点的开发人员，您应该和站点的投资者一起来确定哪一个更重要：站点的外观还是站点的功能。换个角度来说，就是要了解一下站点的格式布局和根据需要进行更改的方便性这两者之间孰重孰轻。大多数情况下，您将发现这些问题的答案会把您引向使用 Web 标准并放宽对站点外观的要求。
本文是质量因素 系列文章之一，将向您展示如何转移 Web 站点的重点和优先级 [并使用 W3C 标准，如XHTML、级联样式表（CSS）和文档对象模型（DOM）] 来减少维护时间、宽带费用以及所编写的特定于浏览器的代码量。
维护梦魇
SHEEP Web 小组被指派去增强 SHEEP 客户销售应用程序 —— 一个典型的电子商务站点，此站点主要包含产品目录和购物车。该小组注重到的第一件事情是这个站点非常有吸引力。它以生动有趣的方式来展示公司的产品。但是用户满足度调查却反复表明用户对于大量的产品描述和产品细节以及对产品进行比较的能力都不满足。
Web 小组的任务是向该商务站点添加更多内容，并增加产品比较功能。在小组进行修改时，他们至少碰到了两个主要的难题：
代码是和表及小的间隔图片一起装入的，目的是得到所需布局。当添加新行或列来显示新的内容时，很轻易出现排版错误。在很多浏览器上对每个更改进行测试后，该小组才发现了此类错误。复杂的表布局还增加了确定在何处做更改或添加内容所需的时间。
应用程序有几百行 JavaScript 代码专门用来补偿浏览器差异和非凡效果。遗憾的是，对该代码进行的最后一次维护是在引入流行的浏览器（例如 Firefox?）之前。结果，小组投入了大量的时间来修改 JavaScript 代码，以便应对较新的浏览器。
重新考虑优先级
鉴于目前所面临的问题，SHEEP 小组的架构师告知项目经理该站点的代码很难进行修改，并且该项目所需时间将远远超出当初所估计的。出于好奇，项目经理查看了 Web 站点的历史，以便查明是否有非凡原因导致该站点难于进行维护。结果表明影响该站点的两个主要因素是兼容性和外观。
该站点的第一个决定因素是对旧浏览器的向后兼容性。该站点是在 Web 早期发布的。随着站点的发展以及 Web 技术的提高，公司添加了新功能。为了确保受众尽可能地大，该站点被设计为可用于当时所有的流行浏览器。为了将浏览器市场快速变化的影响降至最低，公司决定将站点的 HTML 标记锁定在通常会被 Microsoft? Internet Explorer? 5 和 Netscape? 4 所支持的层面上。正是这个层面的兼容性导致了页面布局中额外的复杂性，并且需要使用 JavaScript 代码来添加新功能。
第二个决定因素是页面外观在不同浏览器中的一致性。页面经过了精心布置，因此无论是在 Internet Explorer、Netscape、 Opera 还是其他图形化浏览器中进行显示时，页面的外观几乎是相同的。为了实现这个目的，页面使用了大量嵌套的表和小的间隔图片，用来强制表单元格宽度。
带着这项调查结果，项目经理找到了站点主办方，然后问道：“假如只有不到 0.5% 的用户使用这些旧浏览器，那么这种兼容性是必需的吗？并且，假如可以用其他方式来树立品牌形象，那么不同浏览器中的相同外观是必需的吗？”
迁移到 Web 标准
销售应用程序示例说明了由不适当的侧重点所引起的质量问题，比如为了支持旧浏览器版本所增加的维护时间，以及为了包含特定于浏览器的标记和代码的大型 Web 页面所增加的带宽开销。幸运的是，假如使用万维网联盟（W3C）Web 标准，就能够很轻易地解决此类问题。
在 2003 年之前，Web 页设计的复杂性是由于缺少标准的或一致的 HTML 实现而导致的。浏览器通过添加对 HTML 语言的扩展来相互竞争。它们对 JavaScript 代码和文档对象模型（DOM）的支持情况也各有不同。因此，开发人员不得不创建方法以确保 Web 页面在不同浏览器中的外观是相同的。所用的技术包括使用表格对图片文本进行像素级定位、特定于浏览器的客户机和服务器代码、利用了浏览器代码中的特性或 bug 的编程等。
2003 年左右，开始出现标准的融合和支持这些标准的浏览器。1998 年开始，W3C 发布了 Web 标准以便提供规范和准则，使开发人员与浏览器实现能够相互协调。很多浏览器（例如 Netscape 4 和 Internet Explorer 5）开始实行部分 W3C Web 标准。但是，直到 2003 年，随着 Mozilla?、Netscape 6、Internet Explorer 6、Opera 7 和 Firefox 的发布，浏览器的兼容程度才达到现在的水平。虽然这些浏览器中没有一个是完全支持 W3C 标准的，但每一个又都非常接近标准，从而使开发人员可以基于主要的标准来编写代码，而不是基于特定于浏览器的实现。
现在所使用的 Web 标准致力于 Web 页面的三个方面：结构、表现形式和行为。新的准则和法律要求也触及了质量方面的问题，即可访问性。我将在下面各节中讨论这些内容。
结构：XHTML
HTML 是最初的 Web 页面标记语言。现在的 Web 标准中，HTML 已经由 XHTML 代替。随着 XML 被广泛采纳，W3C 将 HTML 重构为与 XML 兼容。得到的结果是基于 HTML 4.0 的 XHTML 1.0。使用 XHTML 的一个优点在于支持 HTML 文档的旧浏览器可以读取并正确处理 XHTML 文档。此外，由于 XHTML 是与 XML 兼容的，所以 XHTML 文档不能出现缺失的标记或不正确关闭的元素 —— 而这正是很多 HTML 文档中普遍存在的一个问题。
XHTML 的 Web 标准为 Web 页面标记语言定义了新的使命。在 XHTML 中，标记语言将仅传递内容和结构 —— 标题、段落、编号列表和定义列表等。而表现形式则更改为 CSS。从对 HTML <FONT> 标记及其他基于表现形式的标记的反对中就可以看出这种转变。
表现形式：CSS
W3C Web 标准定义了两级级联样式表（CSS）标准 —— CSS1 和 CSS2。撰写本文时，CSS3 标准还在开发中。CSS 标准定义了表示语言，用于指定 Web 页面的格式 —— 版式、布置、布局和颜色等。
CSS 答应站点的设计人员将表现形式和格式的具体说明放置在独立于 Web 页面 XHTML 文档的单独文档中。这样将答应重新使用，并且减少了必须随每个 Web 页面下载的文本数量。大多数与标准兼容的浏览器都提供了一定程度的对 CSS 文档的缓存支持。这也提供了灵活性，对一个文档进行更改不会影响另一个文档。例如，假如一些 Web 页面共享相同的 CSS 文档，则对该 CSS 文档所作的更改将反映在使用该样式表的所有页面上。
行为：ECMAScript 和 DOM
Web 标准关注的第三个方面是行为，使用 DOM 和 ECMAScript 指定。文档对象模型 (DOM) 指定了 Web 页面的表示方法和相关的浏览器对象，因此可以通过 ECMAScript 程序进行访问和操作。ECMAScript 是 JavaScript 语言的标准化版本，减少了旧浏览器脚本语言（例如 Netscape 的 JavaScript 和 Microsoft 的 Jscript）的不兼容性。使用 DOM 和 ECMAScript，Web 开发人员可以添加高级行为和操作，改善用户的 Web 体验。例如，您可以在浏览器（而不是服务器）的 Web 表单上执行字段验证。
可访问性：WAI 和 Section 508
Web 页面的质量方面也通过一套准则和规定进行了标准化。W3C 建立了一套准则，利用 Web Accessibility Initiative（WAI）来改善 Web 站点的可访问性。美国政府通过 US Code 的 Section 508 建立了用于 Web 站点可访问性的一套规定。其他很多国家也在相应的法律中考虑了类似的可访问性规定和准则。
可访问性准则的目的在于确保残疾人可以使用 Web 页面。设计可访问页面的一个有趣的副作用是它更适用于移动设备（例如 PDA、移动电话等）。
宽松的外观要求
除了向后兼容性要求外，SHEEP 小组的架构师注重到该站点陷入了这样的困境即过多使用代码来加强其在不同浏览器中的外观。这是引起问题的 Web 站点设计的诸多旧思路之一。
出于多种原因，早期的 Web 设计人员和站点主办方坚持认为其站点在所有浏览器中的外观应该是相同的。这种主张超出了对相似外观和页面可读性的要求。它要求在每个浏览器的每个页面上，都具有相同像素定位的元素和相同的字体大小。开发人员将大量时间花费在装饰 Web 页面上以确保相同的外观。
现在您应该探究一下其原因。Web 站点在不同浏览器中具有相同像素的外观有什么优势？
用户从相同的外观得到好处了吗？并非如此。大多数用户只使用单一的浏览器，因此他们仅采用一种方式来查看站点。他们并不在意站点在其他浏览器中的外观。
相同的外观能更好地维护公司的品牌形象吗？不见得。公司的品牌是通过样式、颜色、所使用的商标和徽标以及表现形式来共同建立的。公司经常改变其商标或徽标的外观以适应产品的需要。例如，大家熟知的 IBM 徽标就有各种形式 —— 单色八条线、单色十三条线、三色八条线（如很多 Thinkpad 上所示）、图标符号（眼睛和蜜蜂图标）等等。
在各浏览器中获得接近一致的外观就足够了。使用 W3C Web 标准的一个优势在于与标准兼容的浏览器将以相当一致的方式来显示页面。使用这些标准，能够以最少数量的编码获得最为接近的外观，因此，可以大大减少需要维护的代码数量。
Web 标准的好处
由于篇幅所限，不能具体演示 SHEEP 小组使用 W3C Web 标准来重构该销售网站的所有必需操作。可以在 参考资料 中找到一些关于 Web 标准迁移的文章和书籍。只考虑 Web 站点的质量方面，迁移到 Web 标准和放宽对站点外观的要求将得到至少三个方面的改良，如下所述。
易于维护
清单 1 是一个基于表的导航菜单的简化的 HTML 示例。
清单 1. 基于表的导航菜单的简单 HTML
示例代码 [www.mb5u.com]
<table border="0" align="center" cellpadding="0" cellspacing="0">
<tr valign="top">
<td width="100"><font color="blue" size="-1">Menu item 1</font></td>
<td width="100"><font color="blue" size="-1">Menu item 2</font></td>
<td width="100"><font color="blue" size="-1">Menu item 3</font></td>
</tr>
</table>
<tr valign="top">
<td width="100"><font color="blue" size="-1">Menu item 1</font></td>
<td width="100"><font color="blue" size="-1">Menu item 2</font></td>
<td width="100"><font color="blue" size="-1">Menu item 3</font></td>
</tr>
</table>
现在看一下 清单 2，它演示了采用 XHTML 编写的相同导航菜单，并将表现形式移入独立的 CSS 文档（我没有展示 CSS）。
清单 2. 采用 XHTML Web 标准的导航菜单
示例代码 [www.mb5u.com]
<ul id="navigationMenu">
<li>Menu item 1</li>
<li>Menu item 2</li>
<li>Menu item 3</li>
</ul>
<li>Menu item 1</li>
<li>Menu item 2</li>
<li>Menu item 3</li>
</ul>
显然，采用 Web 标准的版本包含更少的代码。还注重到，使用 XHTML 将减少对大块语句进行复制-粘贴编辑时所引起的问题，例如复制整个 <td></td> 子句。
Web 标准对使用了模板（由应用程序处理的 HTML 片断，用于构建发送给浏览器的最终的 HTML）的应用程序肯定有好处。当 HTML 语句分散于多个模板片断时，较简单的语句使您不会再忘记更改模板。
降低带宽开销
清单 1 和 清单 2 展示了 Web 标准解决方案中的文本更少。下面所列的参考资料表明，将传统的 HTML 迁移到 Web 标准实现后，Web 大小和所传输的字节减少了 50% 到 60%。减少的原因是：
示例代码 [www.mb5u.com]
表示形式与内容的分离，这样您仅需指定它们一次
消除了间隔图片和其他填充结构来实现所需布局
消除了基于浏览器的编码
消除了间隔图片和其他填充结构来实现所需布局
消除了基于浏览器的编码
假定某公司使用主机服务，该站点每月每 1 GB 传输量需支付 1 美元。使用传统的 Web 页面编码，该公司每月的传输量是 100 GB，则每月应支付 100 美元。迁移到 Web 标准后，该公司的 Web 站点大小减小了 50%。对于相同用户流量，该公司每月仅有 50 GB 的传输量，即节省了 50 美元。
没有用户被拒之门外
迁移到 Web 标准的另一个好处是，消除了依靠于浏览器的代码及用户阻塞。现在一些 Web 站点仍只支持单一的浏览器，通常是 Internet Explorer。糟糕的是，这些站点阻挡了 10% 到 20% 的潜在用户。
使用 Web 标准进行编码的站点可以在旧浏览器和新浏览器中进行浏览。只是在旧浏览器中，站点看起来不够漂亮 —— 更像是 90 年代的早期的基于文本的站点 —— 但内容是可用的、可读的、可访问的。让想使用站点的任何用户都可以访问站点会很有益处，非凡是对于那些提供产品销售的电子商务站点（这一点就更重要了）！
结束语
通过利用 Web 标准以及放宽某些外观要求来改进 Web 站点，可以大大缩减维护时间、增强时间和带宽使用。在兼容 Web 标准的站点中，传递到浏览器的数据量更少，因而带宽占用也更少。新式站点还将表现形式与页面内容分离开来，通过减少与内容传递相关联的操作来简化服务器编程。使用 Web 标准（如 DOM 和 ECMAScript）将减少您必须编写和维护的特定于浏览器的代码数量。并且，寻求不同浏览器间的足够接近的外观而不是完全相同的外观有助于简化 Web 站点的格式复杂性。
作为 Web 站点的开发人员，您应该和站点的投资者一起来确定哪一个更重要：站点的外观还是站点的功能。换个角度来说，就是要了解一下站点的格式布局和根据需要进行更改的方便性这两者之间孰重孰轻。大多数情况下，您将发现这些问题的答案会把您引向使用 Web 标准并放宽对站点外观的要求。
相关Web标准教程：
- 相关链接：
- 教程说明：
Web标准教程-Web标准有效缩减维护时间及Web站点的外观和功能比较
。