Document

精通 HTML5、CSS3 和 XML Web 标准（五）

2024-08-23
dfer
82
VKDoc CSDN

原文：Web Standards Mastering HTML5, CSS3, and XML

协议：CC BY-NC-SA 4.0

十三、最佳实践

除了适当使用 web 标准提供的最佳标记和样式之外，还有一些独立于浏览器的、可靠的、令人满意的设计约定，因此可以作为最终的解决方案来应用。最佳实践应该是网站开发的重中之重。虽然它们会随着时间的推移而变化，但许多可以应用多年。了解提供符合标准的代码的技术，并将它们与那些导致不正确标记的技巧和黑客区分开来是很重要的。

到目前为止，您应该已经了解了标记、样式、新闻提要和其他网站组件的主要 web 标准。是时候学习如何在实践中应用这些标准了，这些标准可以用在任何开发人员的日常工作中。即使符合标准的网页也不一定以有意义的、合乎逻辑的方式提供内容；因此，您应该了解标记元素和 CSS 属性的用途，以最大限度地提高网页质量。最终目标是找到结构、表示和行为的正确组合，并把它们分开，以便利用 web 标准的好处。

恰当地使用元素

web 开发的一个关键点是适当元素的应用。如果适用，请始终应用更具体的元素。以下是一些例子:

表格数据的表格
浮动元素而不是定位组件的表格(非常糟糕的做法)
标题代替一般段落
段落，而不是用断行来分隔行(非常糟糕的做法)
段落用于文本段落，而不是分割
术语及其描述的定义列表，而不是一般段落
标题、文章和章节，而不是一般的div容器(HTML5)
用audio和video元素代替一般的object嵌入(HTML5)

这些项目中的大部分都是严重错误，即使包含它们的网站是有效的。

按逻辑顺序排列的内容

尽管 CSS 样式使得任意定位文档部分和元素成为可能，但是内容应该按照逻辑顺序编写。这种方法具有以下优点:

更易于开发和维护
基于文本的浏览器效率更高
即使没有 CSS，内容也清晰可用(以防.css文件无法加载或样式表被关闭)
通过对听觉浏览器和屏幕阅读器的高级支持来提高可访问性，默认情况下，听觉浏览器和屏幕阅读器在不中断连续性的情况下阅读页面

可靠定位

第九章中讨论的 Coggins 方法可以扩展，不仅可以水平定位，还可以垂直定位。“死点”定位是一种将容器元素定位到屏幕正中央的技术，与分辨率或纵横比无关。它也是独立于浏览器的。例如，在 800 × 600 层的情况下，可以应用清单 13-1 中的规则。

清单 13-1。“死点”定位

#wrapper { position: absolute; left: 50%; top: 50%; margin-left: -400px; margin-top: -300px; width: 800px; height: 600px; }

当然，如果这种技术用于加载屏幕上的徽标，则应通过将顶部偏移量减少到所需值来应用比例，如 2:3、1:3或黄金分割。但是，您应该考虑到，非常小的图像或简短的文本在不同的屏幕上看起来完全不同。此外，如果定位的层大于浏览器窗口的分辨率，部分内容将被截断，并且对于某些用户来说变得不可访问。因此，定位的图层不应大于目前全球使用的最小分辨率(该分辨率在不断提高)。有几种替代解决方案，如分辨率检测、特定于媒体的样式表(例如，最大化移动设备的宽度)或具有流动布局的独立于浏览器的设计。后一种，液体布局，在设计允许内容根据可用空间跨越整个页面宽度的所有情况下都是理想的(根据需要扩展或收缩 ¹ )。

尺寸和比例

样式表的有效性不能保证正确的大小和比例。CSS 单元的选择对网页组件的整体外观以及内容的可用性和可读性有很大的影响。

¹ Liquid layout 不仅适用于不同分辨率，也适用于相同分辨率下的大小调整窗口。

相对单位长度

CSS 的相对单位(em和%)是根据另一个元素的特征计算的，应该用于长度。

只有在目标媒体的物理特性已知的情况下，才能使用绝对单位，如英寸、厘米、磅和十二点活字。一个典型的例子是网页的打印选项，其中官方文档的默认输出可以是 12pt Times New Roman，在标准尺寸的纸张上具有 2.5 cm 的边距，例如北美信纸(8.5 ×11”)或标准 A4 纸(210 × 297 mm，ISO 216 国际标准 [1 ])。

正确组合单元

在 CSS 中可以使用em单元来提供可伸缩的样式。它是测量长度的通用单位，如页边距或元素填充。它允许开发人员指定几个与当前字体大小相关的 CSS 属性。因此，即使用户放大了字体大小，以此单位声明的边距也保持成比例。

为了简化在em中表示的字体大小的计算，用户体验专家 Richard Rutter 介绍了一种技术，在body元素上应用 62.5%的字体大小(清单 13-2 ) [2 )。

***清单 13-2。*拉特法

body { font-size: 62.5%; }

由于许多用户代理样式表使用的 16px 默认大小的 62.5%是 10px，前面的规则使清单 13-3 中的规则样式的段落字体大小为 12 像素，因为1.2:10 = 12 px。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传注意尽管该值被广泛应用，但它并不完全可靠，在某些浏览器中可能会有所不同。

***清单 13-3。*使用鲁特法轻松计算字体大小

p { font-size: 1.2em; }

虽然基于em的大小调整可以用来确保在任何屏幕上可读的字体大小，但这种方法有一个已知的问题。如果用户更改默认字体大小或在浏览器中应用缩放，文本可能会变得不可读。另一方面，以像素为单位设置的字体大小在不同的环境中很健壮，但与其他元素和屏幕不成比例。分辨率越大，字体越小。此外，浏览器的内置文本缩放不能在所有情况下用于基于像素的字体大小的内容。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传注意由于浏览器之间的差异，网页上的字体大小是具有挑战性的。IE7+中的放大镜功能不会在所有情况下统一缩放绝对定位的内容(有时会缩小)。IE 支持使用%、em或命名大小设置的字体缩放和文本大小更改。在 Firefox 2 及更早版本中，仅支持文本大小更改；然而，改变pt和px字体的大小也可能超出%、em中设置的大小，或者使用命名大小声明。Firefox 3+支持缩放和文本大小更改。Opera 9+还有缩放功能。缩放在不同的浏览器下可能会产生不同的结果，这取决于与页面相关联的内容和样式。

正确嵌入外部内容

由于 Web 是一个真正完整的多媒体平台，所以网页通常具有嵌入的视频剪辑、交互式对象和其他外部组件。然而，由于内容资源提供了不正确的嵌入代码，因此在许多情况下需要额外的任务来使它们符合标准。此外，由于随嵌入代码一起提供的代码不充分，有时无法执行标准化。即使 web 开发人员标准化了无效的嵌入代码，他们也无法纠正相关的名称空间、脚本和其他组件。一个很好的例子就是脸书 ² 的经典“喜欢”盒子。在 Facebook.com 的开发者部分生成的嵌入代码所提供的名称空间和词汇不一致。开发人员在 Web 上使用的“解决方案”之一是将不正确的标记部分添加到 JavaScript 函数中，如清单 13-4 中的函数，它将由撇号分隔的标记片段写入(X)HTML 源代码。 ³

***清单 13-4。*一种广泛使用的嵌入无效代码的伎俩

**document.write('**<script src="http://connect.facebook.net/en_US/all.js#xfbml=1"></script> ![images](https://gitee.com/OpenDocCN/vkdoc-html-css-zh/raw/master/docs/web-std-master-h5c3-xml/img/U001.jpg) <fb:like-box href="http://www.facebook.com/pages/Your-page/122946805997761" width="280" ![images](https://gitee.com/OpenDocCN/vkdoc-html-css-zh/raw/master/docs/web-std-master-h5c3-xml/img/U001.jpg) show_faces="true" stream="false" header="false"></fb:like-box>**');**

如果直接写在标记中，相同的片段会在验证器中给出错误消息。按钮的iframe版本也有问题，因为它不能在 XHTML 中使用。可以重写为一个object(参数相同)，但是之后就停止工作了。API 和第三方软件组件的用户如果希望他们的 web 页面得到验证，通常会使用前面的技巧。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传警告用 JavaScript 提供 document.write 的标记代码是一种你不应该使用的黑客技术。同样的技巧也适用于验证几乎任何类型的不正确的标记，这些标记肯定不能被真正的 web 标准所接受，即使这些标记代码是有效的。它当然会进行验证，因为验证器不会考虑外部.js文件中写入的内容。此代码仍然无效！然而，在许多情况下，如何在不牺牲功能性或有效性的情况下提供这样的内容是一个悬而未决的问题。

幸运的是，脸书从 2011 年秋季开始为“喜欢”按钮和盒子提供有效的 HTML5 嵌入代码。然而，经典的嵌入代码仍然在许多网站上使用。

³ 假设启用了 JavaScript

将 YouTube 视频嵌入为有效的 XHTML 或 HTML5

流行的视频分享门户网站 YouTube 为 YouTube 视频提供了两种类型的嵌入代码:

老式的嵌入代码应用带有参数的object元素和一个embed元素。它只支持 Flash 播放。
新的嵌入代码使用了一个iframe，支持 Flash 和 HTML5 视频内容。

在 YouTube 上的每个视频下，都有一个分享按钮，提供了当前视频的链接，并带有长链接、高清链接和声明播放的开始位置等选项。在链接区域下方，有一个嵌入按钮。单击它后，会出现一个文本框，其中包含所选的新型嵌入代码，可以复制到剪贴板。在这个文本框下面，还有更多定制嵌入代码的选项，比如声明大小 ⁴ 或者使用旧式的嵌入代码。

从标准化的角度来看，两个版本都需要一些改进。

在 XHTML 中，应该解决以下问题:

旧式嵌入代码包含的embed元素在 XHTML 中无效。
新型嵌入代码使用的iframe元素在 XHTML 1.0 Strict 或 XHTML 1.1 中不能使用(仅在 XHTML 1.0 Transitional 中，不应使用)。此外，应该提供data和type属性来最大化互操作性(没有它们，嵌入将无法在某些浏览器下工作)。然而，提供data属性，同时从建议的嵌入代码中保留movie参数，可以确保浏览器独立性，因为一些渲染引擎将使用外部声明(object元素上data属性的值),而其他渲染引擎将使用内部声明(movie参数的值)来标识要从中检索视频的 URL(类似于第九章中介绍的用于 Flash 嵌入的 Flash Satay 方法)。

在 HTML5 中，应该解决以下问题:

如果您喜欢新型嵌入代码，那么frameborder和allowscreen属性不应该用在iframe元素上。
如果您想使用旧式代码，object元素中缺少data和type属性。此外，param元素和embed元素应该使用简写符号来结束，而不是使用结束标记</param>和</embed>。

假设我们想用清单 13-5 和清单 13-6 中的嵌入代码嵌入视频。

⁴ 使用嵌入代码时，尺寸也可以在标记中任意修改。

***清单 13-5。*新的嵌入代码，例如 YouTube 建议的视频

<iframe width="560" height="315" src="http://www.youtube.com/embed/L2tuL_2Q3vA?rel=0" frameborder="0" allowfullscreen></iframe>

***清单 13-6。*新型嵌入式代码，例如 YouTube 建议的视频

<object width="560" height="315"><param name="movie" value="http://www.youtube.com/v/L2tuL_2Q3vA?version=3&hl=en_US&rel=0"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/L2tuL_2Q3vA?version=3&hl=en_US&rel=0" type="application/x-shockwave-flash" width="560" height="315" allowscriptaccess="always" allowfullscreen="true"></embed></object>

在 XHTML 中，旧式的嵌入应该是首选的，并做相应的修改(清单 13-7 )。

***清单 13-7。*XHTML/html 5 中的标准化嵌入代码

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传注意不要忘记应用文档类型的嵌套规则。在 XHTML 1.0 Strict 中，object元素要包装在div或p等容器元素中；否则，代码将无法验证。

同样的代码也可以用在 HTML5 中，其中的embed元素也可以被保留；但是，可以安全地删除它:前两行确保了浏览器独立性。在 HTML5 中，也可以使用新型的嵌入代码。可以通过移除frameborder和allowfullscreen属性来标准化(清单 13-8 )。

***清单 13-8。*嵌入 HTML5 的符合标准的 YouTube】

将谷歌地图嵌入为有效的 XHTML 或 HTML5

定义办公室、餐馆等位置的一种流行方法是嵌入交互式 Google Maps 对象。

谷歌地图提供的源代码类似于清单 13-9 中的。

***清单 13-9。*谷歌提供的一个谷歌地图嵌入代码

然而，该代码不符合标准。在 HTML5 中，应该删除frameborder、scrolling、marginheight和marginwidth属性(样式应该通过 CSS 实现)。在 XHTML 中，嵌入代码应该修改如下:

由于 inline frame 元素(iframe)不能在 XHTML 1.0 Strict 和 XHTML 1.1 中使用，所以应该用object标签代替。
type属性应该用值text/html来定义；否则，即使代码有效，地图也不会出现。
src属性应该由data属性替换。
应该删除frameborder、scrolling、marginheight和marginwidth属性。
object元素应该被一个p或div容器元素包围。
样式应该由 CSS 定义以适应页面设计(如果默认外观不合适)。

结果应该是清单 13-10 中的形式。

***清单 13-10。*清单 13-9 中嵌入代码的标准化版本

View Larger Map

这种嵌入代码可以在所有现代浏览器上工作，并验证为 XHTML 1.0 Strict、XHTML 1.1 和 HTML5。然而，嵌入了object元素的(X)HTML 文档存在一个问题:旧版本的 Internet Explorer 会忽略 CSS 中由z-index设置的层顺序。

语义网最佳实践

万维网联盟的语义 Web 最佳实践和部署工作组为创作语义 Web 站点提供文档。最重要的如下:

语义网上的图像标注 [4 :该文档描述了图像元数据的重要性和优势。它为基于语义网的图像注释和用例提供了指南。提到了相关的 RDF 和 OWL 词汇表，以及免费工具的概述。
发布 RDF 词汇表的最佳实践方法:该文档为词汇表设计者提供了 RDF 模式和 OWL 最佳实践。
RDFa Primer——桥接人类和数据网 [6 ]:展示了使用 RDFa 符号提供元数据的技术，以及将现有人类可见的文本和链接转换为机器可读数据而不重复内容的技术。还有一个 RDFa 符号的实例，名为“语义仙境中的爱丽丝” ⁷ 。它可以用作提供带有外部词汇表的图像、个人和许可元数据的起点。
在语义网上发布同义词库的快速指南 [8 ]:该文档描述了如何使用 RDF 来表达同义词库的内容和结构，以及相关的元数据。
管理语义网的词汇表——最佳实践 [9 ]:识别、记录和发布词汇术语的外部词汇表可以在广泛的应用中引用和重用。但是，适当的维护是不可避免的。

WAI-ARIA 最佳实践

W3C WAI-ARIA 创作实践指南描述了开发富互联网应用的最佳实践。推荐创建可访问的小部件、键盘导航、表单属性、拖放支持、关系、对话框和可重用组件库的方法。

移动网络最佳实践

越来越多的用户在手机、智能手机或 PDA 上浏览互联网，这些设备的屏幕尺寸和分辨率较小，带宽和容量有限，界面不如台式计算机方便。为它们优化的网页应该以适当的方式设计和提供，以提供合理的用户体验。为移动媒体进行设计时，应考虑移动设备、PDA 和智能手机的具体特性 [11 ]。最重要的如下 [12 ]:

有限的带宽:压缩、缓存和最小化数据大小等技术有助于改善移动用户体验。应尽可能消除 Cookies 和重定向。
有限的处理能力:大的 DOM、巨大的背景图片、大量的脚本等等，都会增加处理时间。因此，用户将不得不等待相对较长的时间，这是应该避免的。使用 XHTML Basic 可以为移动设备提供简单的标记 [13 ]。至于风格，CSS 有一个专用于移动设备的配置文件 [14 ]。
有限的技术支持:不依赖脚本、嵌入对象、cookies 或样式表。表格显示应该最小化。由于移动浏览器通常只支持一小部分文件类型，下载部分应该警告用户移动设备不支持的文件格式。
更小的界面:自动签到功能和动态更新页面不变的焦点可以让移动应用的使用更加方便。应尽可能提供预选的默认值。应指定默认文本输入模式、语言和/或输入格式 [15 ]。在确定尺寸和定位时，应考虑小屏幕尺寸和分辨率。绝对单位和像素度量应该被消除。
更难的导航:顶部导航越简单，在移动设备上就越容易使用。应该清楚地确定链接目标。用于可访问性的访问键也可以简化导航。
灵活性:如果对设备进行分类，可以显著提升用户体验。为 JavaScript 提供替代内容非常重要。
特定于移动设备的特性:某些网页组件在移动设备上比在计算机上更容易被利用。例如，电话号码应该具有直拨功能。

在移动设备上呈现网站需要优化。弹出窗口应该完全消除。图形组件不应用于间隔。应该减少图像地图的使用。应该避免的不良做法(如框架或基于表格的布局)会使网页在移动设备上不可用

提供稳健性

Web 开发人员应该确保内容可以使用，即使一些预期的技术无法使用或失败。下面几节将讨论一些常见的例子。

声明备用通用字体

由于计算机可用的字体种类繁多，因此无法保证每个浏览器中都有一种特殊的字体。CSS 规范定义的通用字体系列之一，即serif、sans-serif、cursive、fantasy和monospace [16 ]，应该总是被指定。让我们来看一个 Gill Sans 中提供的文本示例，该示例并不适用于所有用户。可以应用清单 13-11 中所示的规则；它确保文档文本在可用时用 Gill Sans 字体呈现，在不可用时用任何其他 sans-serif 字体呈现。根据应用的浏览器和配置，它可能是 Arial、Helvetica 或类似的字体。

***清单 13-11。*字体的后备机制

body { font-family: "Gill Sans", **sans-serif;** }

当然，你也可以指定更多(最好是相似的)相同类型的字体(清单 13-12 )，第一个可用的字体将被应用，但是通用字体系列声明将一直工作。

***清单 13-12。*通用字体系列之前的相似字体列表

body { font-family: **"Gill Sans", "London", "Corinthian"**, sans-serif; }

具有适当特性的声明

Web 开发人员经常不得不从各种设置和选项中进行选择。一般来说，声明的定义方式应该能够在最广泛的设备和设置上获得期望的效果或功能。例如，CSS 可靠支持的颜色名称仅限于 16 种颜色(如第五章所述)。尽管所有的浏览器都知道它们，并且看起来对开发人员友好，但是十六进制符号应该是首选的，因为 Web 上没有最终的颜色列表。某些浏览器支持额外的颜色名称，但它们不是标准化的。没有理由在 CSS 中混合基本颜色名称和其他颜色符号。毕竟，十六进制记数法可以产生几乎任何颜色。

测试

由于标准化不能保证几个网站特性，测试在大多数情况下是至关重要的。

在多个浏览器中渲染

由于呈现引擎、标记和样式的差异，有效性无法确保在不同的用户代理下正确呈现。因此，在发布之前，应该在所有主流浏览器上检查网站的易读性和功能性。 ⁵ 越复杂的站点设计，在不同浏览器下提供相似的渲染就越复杂。有一些免费的、独立于浏览器的样式表可以消除这项耗时的任务。W3C 核心风格 [17 ]就是很好的例子。

没有样式的可读性

测试网站的一种高级方法是用浏览器的默认样式表来呈现它们。结构合理、逻辑清晰的 web 文档即使没有为它们开发的样式表也能保持清晰易读。这个测试对于检查内容的可访问性也很有用。

⁵ 正如上一章所讨论的，一些浏览器提供了使用不同渲染引擎渲染网页的选项，并且有越来越多的插件可用于测试 browserindependence on tabs。

总结

在本章中，您学习了标准化的最佳实践，这些实践应该与热情的内容作者和开发人员介绍的趋势相区别。您可以在几乎所有场景中安全地应用这些经过时间验证的技术，并提高整体网页质量，从代码优化到健壮的呈现。

使用目前所介绍的技术和标准创建的网站的标准符合性应该通过验证来批准，这将在下一章中描述。

参考文献

ISO (2007)书写纸和某些类别的印刷品-裁切尺寸-A 和 B 系列，以及机器方向的指示。ISO 216:2007。国际标准化组织。www . iso . org/iso/iso _ catalogue/catalogue _ TC/catalogue _ detail . htm？csnumber=36631 。2011 年 9 月 18 日访问
Rutter R (2004)如何使用 ems 调整文本大小。理查德·鲁特。clagnut.com/blog/3482011 年 1 月 25 日访问
Swick R，Schreiber G，Wood D (eds) (2006)语义网最佳实践和部署工作组。万维网联盟。www.w3.org/2001/sw/BestPractices/2011 年 1 月 16 日访问
特朗西 R，范奥森布鲁根 J，潘，斯塔穆 G(编辑)，哈拉谢克-维纳 C，西蒙 N，祖瓦斯 V (2007)语义网上的图像标注。万维网联盟。www.w3.org/2005/Incubator/mmsem/XGR-image-annotation/2011 年 1 月 16 日访问
Berrueta D，Phipps J (eds) (2008)发布 RDF 词汇表的最佳实践方法。万维网联盟。www.w3.org/TR/swbp-vocab-pub/2011 年 1 月 16 日访问
Adida B，Birbeck M (2008) RDFa 初级读本——连接人类和数据网络。万维网联盟。www.w3.org/TR/xhtml-rdfa-primer/2011 年 1 月 16 日访问
阿迪达 B，伯贝克 M (2008)爱丽丝梦游语义仙境。RDFa 符号示例。万维网联盟。www.w3.org/TR/xhtml-rdfa-primer/alice-example.html2011 年 1 月 16 日访问
Miles A (ed) (2005)在语义网上发布辞典的快速指南。万维网联盟。www.w3.org/TR/2005/WD-swbp-thesaurus-pubguide-20050517/2011 年 1 月 16 日访问
Baker T (ed) (2005)管理语义网的词汇——最佳实践。万维网联盟。esw.w3.org/VocabManagementNote2011 年 1 月 16 日访问
Scheuhammer J，Cooper M (eds) (2010) WAI-ARIA 1.0 创作实践。理解和实现可访问的富互联网应用的作者指南。万维网联盟。www.w3.org/TR/wai-aria-practices/2011 年 1 月 16 日访问
Connors A，Sullivan B (eds) W3C (2010)移动网络应用最佳实践。W3C 推荐。万维网联盟。www.w3.org/TR/mwabp/2011 年 1 月 15 日访问
W3C (2010)移动网络应用最佳实践卡。万维网联盟。www.w3.org/2010/09/MWABP/2011 年 1 月 15 日访问
McCarron S，Ishikawa M (eds) (2010) XHTML 基础 1.1 -第二版。万维网联盟。www.w3.org/TR/xhtml-basic/2011 年 1 月 15 日访问
舒伯特 S(编辑)(2008) CSS 移动配置文件 2.0。万维网联盟。www.w3.org/TR/css-mobile/2011 年 1 月 15 日访问
W3C (2010)移动网络最佳实践。W3C 备忘单。万维网联盟。www.w3.org/2009/cheatsheet/#mwbp2011 年 1 月 15 日访问
博斯 B、切利克 T、希克森 I、列 HW (eds) (2010)通用字体系列。在:级联样式表级别 2 修订版 1 (CSS 2.1)规范中。万维网联盟。www . w3 . org/TR/2010/WD-CSS2-2010 12 07/fonts . html # generic-font-families。2011 年 1 月 15 日访问
Bos B (2009) W3C 核心风格。万维网联盟。www.w3.org/StyleSheets/Core/Overview.html2011 年 1 月 16 日访问

十四、验证

网络上使用的各种计算机语言，包括但不限于(X)HTML、CSS、RDF 和 RSS，提供了结构、样式、元数据、语义和其他文档特征。与自然语言相似，它们有自己的语法、词汇和句法需要遵循。然而，就像用自然语言编写的文档中出现的语法、结构或拼写错误一样，web 文档中也可能存在错误。验证是根据 DTD 或模式检查 web 文档源代码的任务。它有助于无错误、干净的代码，并提高整体网页质量。

即使是一个字符也可能影响您精心创建的符合标准的代码，因此定期检查您的文档非常重要。完成必要的例程后，您就能够在源代码级别修改或扩展 web 文档，而不会破坏标准遵从性。在这一章中，你将学习到一些工具，这些工具可以帮助你定位和纠正错误，并保证你的代码没有错误。

概念

标记语言语法规则是由文档类型定义(dtd)定义的。在 HTML5/XHTML5 之前，开发人员应该已经提供了与正在使用的文档类型相关联的 DTD 的引用(如第三章中所讨论的)。

Web 文档可以根据这些规则进行验证，这被称为验证。用于执行验证的工具被称为验证器。成功通过验证的文件被宣称为有效；换句话说，它们没有错误，并且不包含不正确使用的元素或属性。然而，验证既不保证结构良好，也不保证元素的正确使用。有效的文档遵循相应 DTD 中概述的语法规则，这使得用户代理能够正确地构造 DOM 并准确地呈现文档。

应用 dtd 中定义的语法规则在技术规范中有描述，其中大部分由 W3C 发布。

标准一致性是那些满足所有由适当的 DTD 和规范描述的要求的 web 文档的特征。当一个 web 文档按照包含在相应标记语言的技术规范中的形式语法正确编写时，它是有效的，然而一致性涉及整个规范。由于一些一致性需求，比如属性值的正确使用，不能用形式语法来描述，有效性只是一致性的一部分。因此，有效性和一致性可能是相同的，但后者是一个更广泛的术语。

有效的文档是根据所用语言的正式语法编写的。符合标准的文档以推荐的方式应用该技术。

验证不应被视为发布前的最后一步。相反，它应该作为开发的一个重要部分来执行。如果大量使用新的标记元素或属性，而开发人员无法提供 100%的确定性，验证可以帮助识别潜在的错误，并防止无效标记被复制或增加。即使是最有经验的网络标准制定者也可能会发现验证是有用的，并认为它是一种辅助而不是强制性的任务。例如，在向源中插入新的结构元素后，识别大量的——通常是相同的——结束标记(例如四到五个或更多连续的</div>标记)会非常不方便。虽然在包含 100-200 行的文件中找到开始标记-结束标记对非常容易，但对于较大的文件来说，这项任务可能会非常艰巨。 ¹

无论开发人员多么有经验，或者使用多么复杂的开发工具，错误都是不可避免的。这就是验证器可以帮助开发人员工作的地方。正如您将看到的，验证器提供了错误位置，以及可能原因和潜在解决方案的提示。

由于验证有助于整体网页质量，验证器和高级特定检查器也被称为 web 质量保证工具 [2 。

标记验证

HTML/XHTML 文档的主要验证器是位于[validator.w3.org](http://validator.w3.org)的 W3C 标记验证服务。事实上，标记验证服务 1.1 版可用于验证多种类型的标记 [3 ]，包括以下几种:

HTML:ISO/IEC 15445:2000(“ISO HTML”)，HTML 2.0，HTML 3.2，HTML 4.01 框架集，HTML 4.01 过渡，HTML5
MathML : MathML 2.0
微笑微笑 1.0，微笑 2.0
SVGSVG:1。0，SVG 1。1，SVG 1。1 基本，SVG 1。1 Tiny
XHTML : XHTML Basic 1.0，XHTML Basic 1.1，XHTML 1.0 Frameset，XHTML 1.0 Strict，XHTML 1.0 Transitional，以及 XHTML 1.1，XHTML Mobile Profile 1.2，和 XHTML Print 1.0
混合命名空间文档:XHTML+RDFa^{2T5、XHTML 1.1 + MathML 2.0、XHTML 1.1 + MathML 2.0 + SVG 1.1}

W3C 标记验证服务提供了三个选项来验证 web 文档:

直接输入验证:验证文本框中提供的标记。代码可以直接输入，也可以从高级文本编辑器中复制粘贴。这个适合测试。因为没有要验证的物理文件，所以无论是字符编码还是服务器设置都不能通过直接输入来检查。
上传文件验证:验证上传到临时文件夹的文件。也可以检查字符编码。有经验的 web 标准化人员不经常使用此选项，因为文件可以通过同样的努力(在静态文件的情况下)上传到主机(最终目的地)。
URI 的确认:在网络服务器上确认上传的版本。这是验证标记、字符编码和服务器设置的最终验证。它是最终检查和验证他人开发的网页的理想工具。

¹ 即使有工具在开始和结束标签对之间用垂直虚线表示层次结构(例如 Notepad++)。

RDFa 符号可以在 XHTML 文档中得到完美的验证。然而，截至 2011 年，验证器仍然不能识别 HTML5 中的 RDFa，并给出错误。

W3C 验证程序支持以下字符编码:UTF-8、UTF-16、ISO-8859-1、ISO-8859-2、ISO-8859-3、ISO-8859-4、ISO-8859-5、ISO-8859-6-i、ISO-8859-7、ISO-8859-8、ISO-8859-8-i、ISO-8859-9 和 ISO-8859-10

自动检测文档类型和字符编码，并相应地用于验证。如果检测是不可能的，验证器假定文档类型和/或字符编码；然而，结果可能不可靠。适当服务的符合标准的 web 文档总是提供这两种数据；因此，验证器准确地执行验证。也可以手动强制验证器使用特定的文档类型和/或字符编码；但是，在一般情况下不应使用该功能。它应该被认为是一个后备机制，而不是一个重要的功能。

如果标记中有错误，则用红色条纹和错误数量清楚地表示出来(图 14-1 )。甚至网页的图标也变成了红色方块。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-1。*红色条纹以及错误和警告的数量清楚地表明标记是无效的。

默认情况下，连续错误/潜在错误按顺序列在摘要下，换句话说，按发生的顺序(在标记中的位置)排列。可以重写此行为，以便按错误类型对错误消息进行分组。然而，由于许多错误会导致更多的错误(例如丢失结束标记)，因此在大多数情况下顺序检查就足够了。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传提示由于标记错误之间相关性的可能性很高，因此只纠正一些错误(尤其是在文档充满错误的情况下)然后重新验证文档可能更方便。错误的数量可能会呈指数下降。作为直接输入，重新验证对于测试特殊或新标记规范的实现也很有用。

您可以在标准化项目中使用标记验证服务的一些高级设置。可以显示(X)HTML 源代码，错误消息直接链接到相应的行。这对开发人员来说是一个有用的特性。文档标题的树形结构可以通过 outline 选项来可视化，这使得更容易意识到哪个标题被遗漏了(如果有的话)。通过勾选“验证错误页面”复选框，可以验证服务器发送的自定义 404 错误页面除了默认情况下提供的简明报告之外，还可以使用详细输出选项请求更多的解释和更长的建议。W3C 标记验证服务的另一个选项是使用在第十一章中讨论的 HTML Tidy 工具来纠正标记错误。

除了错误位置之外，标记验证服务给出了更正的提示和相应规范和常见问题的链接(图 14-2 )。一些字符可能会被突出显示，这是另一种帮助，有时会使无效字符的检测变得非常容易。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-2。*W3C 标记验证服务清楚地指出错误位置，并提供有用的更正提示。

标记验证结果和建议不仅对缺乏经验的开发人员有用，对专家也有用。使用行号，很容易找到错误，这是纠正错误的先决条件，即使对于那些不依赖于纠正提示的人来说也是如此。

在必要的修正和最终的重新验证之后，结果应该看起来像图 14-3 中的。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-3。*绿色条纹和结果“通过”表示标记有效。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传注意截至 2011 年，验证 HTML5 仍然只是 W3C 标记验证服务的一个实验性功能。因此，验证器会给出一个警告(不是错误！)即使被分析的网页是有效的。验证器不能识别 HTML5 和 XHTML5 文档中的 RDFa 注释。 ³ 此外，与有效的 XHTML 文档相比，validator 不为有效的 HTML5 文档提供带有超链接的验证徽章。如稍后将讨论的，这种徽章可以从单独的站点下载。

W3C 标记验证器不仅是免费的，而且是开源的，可以在 W3C 软件许可 [4 ]下获得。任何人都可以建立服务的镜像或对其开发做出贡献。

XHTML5 中提供的 XML 声明和所有名称空间声明都会导致错误消息，即使它们是有效的。而且，XHTML5 文档的验证结果陈述的是 HTML5 而不是 XHTML5。

虽然网上还有其他的标记验证器，比如 WDG HTML 验证器 [5 ]，或者离线工具，比如火狐插件 HTML 验证器 [6 ]，但是还是推荐使用 W3C 标记验证服务。它是 W3C Unicorn 的一部分，如果还应该检查样式表和提要通道，就可以使用它(参见后面的“W3C Unicorn”一节)。

对于动态网站的开发人员来说，验证标记更加复杂，因为标记验证器通常不能处理 PHP 之类的脚本。检查动态生成的(X)HTML 输出、执行更正和重新验证文档都是真正的挑战。这是动态生成的网页经常无效的主要原因之一。

验证 XML

可以验证 XML 文档是否符合 DTD、XML 模式或模式语言 RELAX NG。语法格式良好是一个基本要求，但它不能保证 XML 的有效性，这有几个约束，如正确使用必需和可选的元素和属性，正确的文档结构和语法，以及正确应用的数据类型。

尽管 XML 验证和解析在逻辑上是独立的任务，但两者通常都是由 XML 解析器执行的。考虑到即使一个错误也可能阻止文档被解析或显示其树结构，web 浏览器的 XML 解析器总是可以用作基本的 XML 验证器。

不是所有的 XML 解析器都需要 XML 有效性，但是根据相关模式检查文档的 XML 解析器需要 XML 有效性。

可以通过 Apache Ant [7 ]的xmlvalidate任务对 XML 文件进行批量验证。例如，清单 14-1 中的目标验证由dir属性指定的目录中的.xml文件。 ⁴

***清单 14-1。*用xmlvalidate 验证 XML

<target name="validate-xml"> <xmlvalidate lenient="no"> <fileset dir="semweb/ont" includes="*.xml" /> <attribute name="http://xml.org/sax/features/validation" value="true"/> <attribute name="http://apache.org/xml/features/validation/schema" value="true"/> <attribute name="http://xml.org/sax/features/namespaces" value="true"/> </xmlvalidate> </target>

验证 RDF/XML

以 XML 序列化格式(RDF/XML)编写的 RDF 文档可以通过 W3C RDF 验证服务在[www.w3.org/RDF/Validator](http://www.w3.org/RDF/Validator) [8 进行检查。可以通过 URI 或直接输入来执行验证。验证器不仅检查 RDF 代码，还表示 RDF 三元组(图 14-4 )。

⁴ 相对于 Ant 构建文件

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-4。*从一个有效的 RDF 文件中检索到的主谓宾三元组

可选地，RDF 图可以以各种格式生成，包括嵌入或链接的 PNG、SVG、GIF、PostScript、IsaViz/ZVTM、HPGL 和 HPGL/2。尽管弧线看起来像手绘的曲线，并且经常相互重叠——这并不是视觉上最吸引人的表现方式——但图像输出对于演示或设计是有用的。同样重要的是要记住，在 Web 上很少有类似的服务可以从 RDF 生成图形图像。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-5。*W3C RDF 验证服务生成的 RDF 图的细节

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传注意与光栅(PNG)输出相反，SVG 输出不仅具有无与伦比的质量，而且还包含作为超链接的 URIs。

可选地，三元组可以以 N-三元组格式显示。节点、弧线和文本的颜色，以及字体大小和方向都可以设置为高级选项。

验证新闻源

因为 RSS 和 Atom 新闻提要应该是有效的 XML 文档，所以必须注意提供没有错误的元素和格式良好的 XML 结构。

万维网联盟在[validator.w3.org/feed/](http://validator.w3.org/feed/) [9 为 Atom 和 RSS 运行 W3C 提要验证服务。与其他 W3C 验证器类似，它不仅提供 URI 验证，还提供直接输入验证。成功验证后，该服务会提供一个“有效 RSS”或“有效 Atom”徽标(取决于经过验证的提要)、一个嵌入代码和一个文本链接。

用于 Atom 和 RSS 的提要验证器和位于[feedvalidator.org](http://feedvalidator.org)的 KML 也可以用于验证 RSS 2.0 和 Atom 1.0 提要 [10 ]。此外，它还验证了blogChannel、dc、itunes、mod_admin、mod_syndication和mod_content、^、、、名称空间的元素。

验证 CSS

样式表验证应该根据使用的 CSS 级别来执行。虽然有效的 CSS1 样式表也是有效的 CSS 2.1 样式表，但在 CSS 2.1 [11 ]中，一些 CSS1 规则集应该用稍微不同的语义编写。由于在 CSS2.1 中省略了某些 CSS 2 特性，所以并非所有的 CSS 2 样式在 CSS 2.1 中都有效 [12 ]。同样，CSS3 中引入的新属性在早期的 CSS 版本中是无效的。有效的 CSS 样式表必须符合相应版本的语法规则，并且必须只包含该规范中定义的 at 规则、属性和属性值。

尽管标记语言版本和变体的选择范围相对较广，但是由于文档类型声明的原因，在大多数情况下可以自动选择用于标记验证的文档类型。然而，CSS 中没有类似的机制，确定要验证的样式表的版本也不是那么简单。首先，CSS 中没有版本声明，其次，词汇表之间有很大的重叠，使得自动版本检测成为不可能。因此，默认情况下，[jigsaw.w3.org/css-validator/](http://jigsaw.w3.org/css-validator/) [13 的 W3C CSS 验证服务根据 CSS 2.1 验证样式表。但是，要应用的配置文件可以作为高级选项手动覆盖。例如，如果你想验证 URI 的 CSS3 文件，你应该构造一个类似于清单 14-2 中所示的 URI ⁶ 。

***清单 14-2。*手动覆盖 CSS3 验证

http://jigsaw.w3.org/css-validator/validator?uri=www.example.com/styles/main.css ![images](https://gitee.com/OpenDocCN/vkdoc-html-css-zh/raw/master/docs/web-std-master-h5c3-xml/img/U001.jpg) ** &profile=css3**&usermedium=all&warning=0&lang=en

⁵ 内容:仅编码

⁶ 当然，您可以从“更多选项”下的下拉列表中选择配置文件“SS level 3”但是，如果您想为 CSS3 按钮提供验证链接，您需要手动构造一个 URI，因为默认代码假定是 CSS 2.1。

与标记验证服务类似，CSS 验证器可以通过 URI、文件上传或直接输入来执行验证。CSS 验证器主要用于验证外部 CSS 文件，但也可以检查内部样式。然而，在后一种情况下，应该首先使用标记验证服务对(X)HTML 文档进行验证。

CSS 验证服务支持 CSS1、CSS2、CSS 2.1 和 CSS3 样式表，以及其他文档配置文件。可以手动选择媒体类型，包括all、aural、Braille、embossed、handheld、print、projection、screen、TTY、TV或presentation。默认介质类型为all。除了错误，验证器可能还会识别警告。由于它们可能是误报或错误的结果，警告可以被隐藏。

验证请求结合基本 URI [jigsaw.w3.org/css-validator/validator](http://jigsaw.w3.org/css-validator/validator)应用参数。支持的参数如下:

uri:待验证单据的 URI。它可以是 CSS 或(X)HTML。
text:要验证的 CSS 文档。
usermedium:用于验证的媒体类型。
output : html (HTML)、xhtml (XHTML，默认)、soap12 (SOAP 1.2)、text(纯文本)。
profile : css1、css2、css21、css3、svg、svgbasic、svgtiny、mobile、atsc tv、tv或none。
lang:报表语言，如en(默认)fr``it``ko``ja``es``zh-cn``nl``de``it或pl。
warning:可能值为no(隐藏警告)、0(较少警告)、1或2(较多警告)的警告级别。2是默认值。

W3C CSS 验证服务的输出类似于 W3C 标记验证器的结果页面。绿色条纹表示有效文件，而红色条纹表示 CSS 文件无效。

验证 I18N

万维网联盟的国际化活动组运行 W3C 国际化检查器 [14 。I18N 检查器可用于根据以下因素检查网页的国际化友好性:

字符编码 : HTTP Content-Type，字节序标记，XML 声明，Content-Type元数据，HTML5 meta charset
语言设置:html元素上的lang和xml:lang属性，HTTP Content-Language，以及content-language元数据
文本方向 : ltr(默认)或rtl
class和id名称:非 ASCII 以及非 NFC 类和标识符
请求头 : Accept-Language，Accept-Charset

验证超链接

最令人失望的浏览器体验之一就是断开的超链接(死链接)。位于[validator.w3.org/checklink](http://validator.w3.org/checklink)的 W3C 链接检查器是一个有用的工具，用于检查 web 文档的内部和外部超链接 [15 ]。链接的文档也可以在最多 150 个文档中递归检查。包含散列标记(如index.html#about)的 URI 片段包含在测试中。不检查robots.txt文件中声明的机器人排除规则禁止的链接(图 14-6 )。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-6。*链接检查器结果

超链接验证不仅对于检查入口点非常有用，而且对于重要文件(如样式表文件、脚本或外部 URIs)也非常有用，这些文件可能会被管理员在不通知的情况下随时修改。例如，永久重定向(HTTP 响应状态代码 301)也由链接检查器识别，尽管它们有效，但是这样的链接应该被更新。该结果可用于消除断开的链接和与所分析的网页的链接相关联的可访问性障碍。

验证可访问性

与其他网站功能不同，可访问性不能由验证器 100%确定地进行验证。虽然标记错误，如不正确的元素使用、缺少标签或结构错误，可以自动识别，但可访问性太复杂，无法自动验证 [16 ]。许多潜在问题需要人工决策、检查或确认。脚本和noscript内容的等效功能、文本描述的充分性、脚本功能和效果、由段落和断行表示的可视列表以及对象中的暂停选项是不能完全确定地自动检查的一些特征。

尽管如此，还是有一些有用的工具可以让易访问性开发人员的工作变得更容易。这种工具应该在网站开发的各个阶段使用，以防止易访问性障碍，修复遇到的障碍，并提高整体网页质量。可访问性工具的主要任务是识别标记中易于访问的元素和属性。此外，某些工具可以帮助开发人员执行那些无法自动验证的检查 [18 ]。可访问性工具根据 W3C Web 可访问性指南(WCAG 1.0 和/或 WCAG 2.0)以及第五百零八部分进行验证。

一个典型的在线易访问性检查工具是加拿大多伦多大学包容性设计研究中心发布的 AChecker ( [achecker.ca](http://achecker.ca) [19 )。AChecker 可以测试网站是否符合各种可访问性准则，包括 WCAG 1.0/2.0 A/AA/AAA 级、第五百零八部分、斯坦察法案和 BITV。该接口通过 URL 或文件上传提供可访问性检查。它识别三种类型的错误:已知的、可能的和潜在的问题。已知的问题被认为是可以确定的错误(例如，img元素缺少alt属性，input元素缺少标签)。可能的问题需要人工决策(例如，误用的元素，select元素上的onchange事件处理程序可能会导致上下文的极端变化)。潜在的问题往往根本不是错误；但是，它们需要人工决策和确认(例如，可能需要dir属性来标识文本方向的变化，数据表可能需要th元素，脚本用户界面可能无法从键盘获得)。不幸的是，并不是每个建议都有效，其中一些是不正确的(例如，如果文档的自然语言是由xml:lang属性标识的，那么在 XHTML+RDFa 中html元素上的lang属性既不有效也不是必需的) (图 14-7 )。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 14-7。 AChecker 提供了好的建议；然而，并不是所有的都是有效的。

AChecker 也支持 HTML 验证。它提供了错误描述和更正建议。

在线可访问性验证工具 Cynthia 可由 URI 根据 508 条款和 WCAG 1.0 对所有优先级 [20 ]进行验证。还提供了高级选项，如浏览器模拟或线路排除。对于处理易访问性的开发人员来说，报告清晰而有用(图 14-8 )。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-8。*详细的可访问性报告，包括解释和 W3C 指南的链接

最全面的辅助工具之一是 WebAIM WAVE [21 ]。这是一个免费的在线工具，在[wave.webaim.org](http://wave.webaim.org)呈现带有可访问性错误、警告和信息的网页(图 14-9 )。它可以识别可访问的属性值、不可访问和潜在不可访问的内容(如 Flash 或脚本)以及依赖于设备的内容(如键盘陷阱)。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-9。*WAVE 呈现的可访问菜单部分

虽然 WAVE 是一个侧重于标记的通用辅助工具，但还有更多特定的工具。例如，有几个免费的在线工具用于评估文本颜色与背景颜色的对比度，如颜色对比度分析仪 [22 ]、光度颜色对比度分析仪 [23 ]，或者威斯康星大学提供的白色背景下彩色文本的索引 [24 。

重要的是要记住，没有任何可访问性工具能够以任何方式执行完整的评估。

随着 HTML5 中新语义元素的引入，必须注意应用最新的可用检查器。

最终的可访问性测试始终是一个现实生活中的测试，涉及由残疾人进行的评估。

验证移动友好性

随着移动浏览的广泛流行，在移动设备上测试你的网站是至关重要的。然而，在各种移动设备上查看网站实际上是不可行的。幸运的是，[validator.w3.org/mobile/](http://validator.w3.org/mobile/)的 W3C mobileOK Checker 可以帮助你分析你的网页是否适合移动浏览 [25 ]。mobileOK 检查器应用 W3C 推荐标准“W3C mobileOK 基本测试 1.0”26 中定义的测试，对故障进行分类，并给出有用的错误描述(图 14-10)。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-10。*W3C mobile ok checker 在评估网站是否适合移动浏览时给出了有用的提示。

更正标记的问题后，网站将满足提供合理的移动浏览体验的基本要求。

统一验证器

虽然单个的验证器可以组合使用来验证完整的网站，但是对于大型项目来说，这是不方便的，而且速度很慢。开发人员可以应用统一的验证器轻松有效地执行多重验证。

W3C 独角兽

2010 年 7 月 27 日，W3C 发布了 Unicorn，这是一个统一的验证器，可以在[validator.w3.org/unicorn/](http://validator.w3.org/unicorn/) [27 买到，口号是“提高网络质量”Unicorn 是最终的标记、CSS、新闻提要验证器和 mobileOK 检查器。验证可以通过 URI、文件上传或直接输入单独或同时进行。高级选项与前面讨论的各个 W3C 验证服务提供的选项相同。独角兽有多种语言版本。

根据所选择的测试，输出提供了关于标记、样式表和新闻提要的有效性，以及网页的移动友好性的信息。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-11。*web 标准化的天堂:有效的标记、有效的样式表和有效的新闻提要

类似于单个 W3C 验证器，有效文档用绿色条纹表示，而无效文档用红色条纹表示。通过单击条纹，可以按类别折叠/取消折叠认证测试结果(默认情况下不折叠)。在右侧，您可以在每个条带中看到错误、警告和信息(如果有)的数量。这些数字是超链接，可用于跳转到页面上的相应部分。对于有效的 web 页面，验证器不仅提供可靠的信息，还提供带有评估链接的 W3C 徽章，这些链接可以嵌入到您的有效 web 页面中。换句话说，Unicorn 的输出与独立验证器的输出是相同的。

总验证器

另一个统一验证器是 Total Validator，它曾经是一个在线服务。相比之下，目前的版本只能作为不同平台的桌面软件工具使用 [29 ]。基本版可以免费下载。Total Validator 可用于不同的平台，包括 Windows、OS X 和 Linux。 ⁷ Total Validator 是一个小而强大的工具，它结合了一个标记验证器、一个可访问性验证器、一个拼写检查器和一个链接验证器(图 14-12 )。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-12。*总验证器配置界面

该界面仅用于启动流程。在声明了要验证的网页的 URI 和参数后，Total Validator 会打开一个浏览器窗口并显示验证结果。错误和警告显示在标记代码中，并带有超链接，链接到标记代码后相应的详细描述条目(图 14-13 )。

基本工具基于 Java，需要 Java 1.5 或更高版本。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-13。*带有一段标记代码(顶部)的验证结果和页面底部的详细描述

除了常见的标记语言，如 XHTML 1.0 Strict、XHTML 1.1 和 HTML5(以及许多旧版本)，Total Validator 还支持 HTML + RDFa 1.1、XHTML + RDFa 1.1、用作多语言的 HTML5，甚至 XHTML5。在 WCAG 的所有级别都可以检查无障碍情况，也可以根据第 508 条进行检查。拼写检查器支持美国和英国英语、法语、意大利语、西班牙语和德语。

Total Validator 提供了在不同浏览器中分析网页外观的截图，包括从 1.5 版开始的各种版本的 Firefox、从 5.5 版开始的 Internet Explorer、Konqueror 3.5、Lynx 2.8、Opera 和 Safari。

一个有趣的选项是，验证结果可以保存为 HTML 格式，下次执行该工具时，只需单击按钮 Last Results 即可打开。

约会网站

一个全面的商业验证器是 SortSite，由 PowerMapper [30 ]开发。其主要特点可概括如下:

可访问性:检查是否符合 WCAG 1.0、WCAG 2.0 和 508 条款。
断开的链接:检查断开的链接和不正确的服务器配置。
兼容性:检查特定于浏览器的代码、脚本和图像格式。
合规性:检查是否符合欧盟和美国法律。
标记和样式 : HTML、XHTML 和 CSS 验证。
搜索引擎优化:查谷歌，雅虎！、和 Bing 内容指南
可用性:根据 Usability.gov 指南进行检查。

提取语义内容

可以使用 W3C 语义数据提取器 [31 ]来检查网站的语义内容。它可以提取如下语义数据:

通用元数据
- 文档标题中提供的标题、作者和描述
- 嵌入在文档正文中的 RDFa 元数据(也以 RDF/XML 格式生成)
相关资源
- 链接文件，例如 RSS 或 Atom 新闻源
文档标题中提供了术语表、版权和书签
文件的大纲
引语和引文

菜单点和 URIs 带有超链接。

另一个全面的语义数据提取工具是位于[inspector.sindice.com](http://inspector.sindice.com) [32 的 Sindice Web Data Inspector。该工具可用于从 URI 或直接输入提供的标记、RDF/XML、Turtle 或 N3 文档中提取 RDF 三元组。Sindice Web Data Inspector 可以专门用于检索语义数据(Inspect 按钮)或组合语义数据提取和验证(Inspect + Validate 按钮)，以及本体分析和推理(图 14-14 )。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-14。*Sindice Web Data Inspector 开始屏幕上的综合选项

因此，该工具提供了从文件中检索到的主谓宾三元组的完整列表(图 14-15 )。输出格式也可以更改为 N-triples 或 RDF/XML。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-15。*语义数据提取正在进行中

“适马”选项是机器可读元数据的一个很好的例子。软件工具可以从正确编写的语义文档中提取结构化数据，并任意显示(图 14-16 )。这是语义网的真正本质！

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-16。*从 RDF 中提取个人描述，并以视觉上吸引人的方式显示

Sindice Web Data Inspector 的一个非常好的特性是可以从语义文档生成一个可伸缩的图(图 14-17 )。该图不仅显示了三元组，还提供了文件中使用的本体和词汇的快速总结。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-17。*从 RDF 文件生成的可扩展图形

Sindice Web Data Inspector 还有一个带有两个不同选项的验证功能。第一个称为“RDF 语法验证”，根据 W3C 规范执行 RDF 语法验证。第二个选项是“学究式验证器”，它对提取的三元组进行验证。在有效文档的情况下，两个验证器都给出结果“有效文档”

表示有效性

网站的标准一致性可以通过“有效”图标(也称为有效性徽章或有效性标志)来轻松表达。除了通知读者，如果使用得当，它们还可以用作即时验证链接。在验证 web 文档时，W3C 验证器自己提供的示例代码中列出了预期的超链接(图 14-18 )。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-18。*带有嵌入代码的 W3C 验证图标

请注意，这些代码只是建议。例如，img元素上的style属性可以省略，以支持外部 CSS 规则。XHTML [33 ]的推荐嵌入代码在清单 14-3 中给出。

***清单 14-3。*嵌入 W3C 验证图标的代码

W3C 图标

W3C“有效”图标在左边代表 W3C 标志，在右边代表建议(图 14-19 )。在许多情况下，还会显示版本或建议。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

***图 14-19。*传统 W3C 有效性图标的结构

图标的默认大小为 88 × 31 像素。万维网联盟为每个图标提供了两个版本:金色和蓝色。内容作者可以自由选择使用哪一个。W3C 商标许可以及徽标和图标使用政策适用于所有 W3C 有效性图标。不允许修改图标。

W3C 有效标志只能在通过验证的网页上使用。它们是为验证而设计的。图标必须提供一个超链接，根据相应的 W3C 技术或标准来验证网页。因此，单击正确设置的“有效标记按钮”会将页面的 URI 传递给 W3C 标记验证服务，该服务会给出相同的结果页面，就好像 URI 直接用于验证器网页上的验证一样。CSS 验证按钮也是如此。因此，内容提供商和 web 开发人员也可以使用这些按钮在每次修改页面时重新验证页面。专家可以使用该工具来确保自己对最新修改的了解，而无需加载相应的验证器和手动添加 URI。

万维网联盟不验证网页的有效性；因此，确保一致性和一致性是开发者和 Web 作者的责任。

W3C 质量保证网站 [34 ]上列出了 W3C 验证图标的完整列表，包括以下内容:

标记图标:“HTML 2.0”、“HTML 3.2”、“HTML 4.0”、“HTML 4.01”、“ISO/IEC 15445 的 ISO-HTML”(遗留缺失)、“XHTML 1.0”、“XHTML 1.1”、“XHTML Basic 1.0”、“XHTML-Print 1.0”、“XHTML+RDFa”
CSS 图标:一个通用有效的“CSS”图标和更多用于“CSS 1 级”和“CSS 2 级”的特定图标
XML 图标:“XML 1.0”、“XML 1.1”
【SVG icons】??【SVG 1】。0、“SVG 1”。1、“SVG 1”。2、“SVG Tiny 1”。1 “、” SVG Tiny 1 “。” 2 "
MathML 图标:【mathml 2.0】

有效性图标也可以直接从 W3C 图标库获得(和其他图像一起) [35 。

代表技术

除了验证之外，还有许多图标可以用来表示网站使用的 web 技术。他们不仅可以表达潜在的技术，还可以表达贡献、网站开发者同意的倡议，或者他们同情的项目和组织。它们还可以用来自豪地展示很少实现但在其他网站上几乎看不到的高级功能。最常用的 W3C 技术图标如下:

"HTML5 "
- " HTML5 支持 CSS3/Styling "
- " HTML5 支持语义"
- “HTML5 支持离线和存储”
- " HTML5 支持连接/实时"
- “HTML5 支持多媒体”
- HTML5 支持图形、3D 和效果
- " HTML5 支持设备访问"
- “HTML5 Powered with Performance & Integration”
  
  技术名称是可选的，可以组合在一起(通过在最后选择的技术前添加单词“and”)。徽章可以用徽章生成器 5000 在水平和垂直方向上生成。带有或不带有 wordmark 的 HTML5 标记、支持元素、技术类别和贴纸模板可作为单独的 SVG 和 PNG 文件使用。HTML5 徽标也有单色版本。所有徽章都使用知识共享署名 3.0 许可证 [36 ]发布。
“用层叠样式表制作”。
辅助功能图标:“威-A WCAG 1.0”、“威-AA WCAG 1.0”、“威-AAA WCAG 1.0”37、“威-A WCAG 2.0”、“威-AA WCAG 2.0”、“威-AAA WCAG 2.0”38。
语义网技术按钮:“GRDDL”、“OWL”、“POWDER”、“RDF”、“RDFa”、“RIF”、“SKOS”、“SPARQL”39。

然而，W3C 并不是唯一发布技术图标和徽标的机构。以下是一些例子:

" Unicode 编码"
“此处使用都柏林核心”
“Java—立即获取”
“HCARD”、“XFN 友好”以及其他微格式的图标和徽标 [40
“辛西娅测试”41
“搜索引擎友好”
没有弹出窗口，没有间谍软件
“由 PERL 提供支持”
page rankn/10—pr checker . info(其中 n 是 1 到 10 之间的数字) [42 ]

总结

在这一章中，你了解到有强大有效的工具来检查你的 web 文档中的错误。它们可以在开发过程中使用，对于重新设计非常有用。许多这样的验证器都是免费工具，可以在线获得。最常用的是标记验证器和 CSS 验证器，因为标记和样式表是可以自动验证的基本网站组件。验证网站的可访问性是一个真正的挑战，因为 WCAG 的几个方面经常需要人工决策。

最后一章将列举导致无效标记、样式表、新闻订阅频道和可访问性障碍的最常见错误。

参考文献

Murphy C，Persson N (2009)有效代码不一定是结构良好的代码。在:HTML 和 CSS 网络标准解决方案-一个网络标准化的方法。伯克利艾德的朋友
Thereaux O，Lacourba V 等人(eds) (2010)网络质量保证工具。www.w3.org/QA/Tools/2011 年 1 月 7 日访问
W3C(2011)W3C 标记验证服务 1.1 版。万维网联盟。validator.w3.org2011 年 1 月 4 日访问
W3C(2011)W3C 标记验证器的源代码可用性。万维网联盟。validator.w3.org/source/2011 年 1 月 4 日访问
奎因 L (2007) WDG HTML 验证器。利亚姆.奎恩。www.htmlhelp.com/tools/validator/2011 年 1 月 4 日访问
Gueury M(2010)Firefox 的 HTML 验证器插件。马克·古里。addons.mozilla.org/en-US/firefox/addon/249/2011 年 1 月 8 日访问
Apache Ant 项目(2010) XMLValidate。阿帕奇软件基金会。ant.apache.org/manual/Tasks/xmlvalidate.html2011 年 1 月 26 日访问
Prud’hommeaux E (2007) W3C RDF 验证服务。www.w3.org/RDF/Validator2011 年 1 月 5 日访问
Thereaux O 等人(2010) W3C 提要验证服务，用于 Atom 和 RSS。万维网联盟。validator.w3.org/feed/2010 年 11 月 30 日访问
Ruby S，Pilgrim M，Walton J，Ringnalda P(2009)Atom、RSS 和 KML 的提要验证器。萨姆·鲁比，马克·皮尔格林，约瑟夫·沃尔顿和菲尔·林纳尔达。feedvalidator.org2010 年 11 月 30 日访问
博斯 B、切利克 T、希克森 I、列 HW(编辑)(2010)CSS 2.1 语法。在:级联样式表级别 2 修订版 1 (CSS 2.1)规范中。W3C 工作草案。万维网联盟。www.w3.org/TR/CSS/grammar.html2011 年 1 月 5 日访问
博斯 B，切利克 T，希克森 I，李 HW(编辑)(2010)符合性:要求和建议。在:级联样式表级别 2 修订版 1 (CSS 2.1)规范中。W3C 工作草案。万维网联盟。www.w3.org/TR/CSS/conform.html2011 年 1 月 5 日访问
W3C 质量保证(2011) CSS 验证服务。万维网联盟。jigsaw.w3.org/css-validator/2011 年 1 月 5 日访问
W3C I18N 活动组(2010 年)。万维网联盟。qa-dev.w3.org/i18n-checker/2010 年 9 月 30 日访问
W3C (2010) W3C 链接检查器。万维网联盟。validator.w3.org/checklink2011 年 1 月 5 日访问
Abou-Zahra S (ed) (2010)评估网站的可访问性:概述。万维网联盟。www.w3.org/WAI/eval/Overview.html2011 年 1 月 6 日访问
Abou-Zahra S (ed) (2006)网站可访问性评估工具的完整列表。万维网联盟。www.w3.org/WAI/ER/tools/complete.html2011 年 1 月 6 日访问
Abou-Zahra S (ed) (2010)选择网页可及性评估工具。万维网联盟。www.w3.org/WAI/eval/selectingtools.html2011 年 1 月 7 日访问
ATRC (2009)阿契克(网页可及性检查者)。多伦多大学。 achecker.ca 。2011 年 9 月 19 日访问
他的软件(2010)他的软件辛西娅说门户。www.cynthiasays.com/软件公司。2011 年 2 月 4 日访问
Kasday L，Andersen A，Smith J，Hernandez D，Bohman P，Anderson S，Maturi N，Varanasi B，Parija J (2011)波。网页可及性评估工具。牢记网页可访问性。wave.webaim.org2011 年 2 月 3 日访问
Johansson D (2010)色彩对比分析仪。唐纳德·约翰逊。www.colorsontheweb.com/colorcontrast.asp2011 年 2 月 3 日访问
柠檬 G (2011)光度色对比度分析仪。多汁工作室。juicystudio.com/services/luminositycontrastratio.php2011 年 2 月 3 日访问
UoW (2011)颜色对比样本索引。威斯康星大学。trace.wisc.edu/contrast-ratio-examples/index.htm2011 年 2 月 3 日访问
W3C (2010) W3C mobileOK 检查器。你的网站对手机友好吗？万维网联盟。validator.w3.org/mobile/2011 年 9 月 19 日访问
Owen S，Rabin J (eds) (2008) W3C mobileOK 基本测试 1.0。W3C 推荐。万维网联盟。www.w3.org/TR/mobileOK-basic10-tests/2011 年 9 月 19 日访问
W3C (2011) Unicorn -统一验证器。万维网联盟。validator.w3.org/unicorn/2011 年 1 月 7 日访问
W3C (2010)对 Unicorn 的翻译。万维网联盟。validator.w3.org/unicorn/translations2010 年 9 月 23 日访问
Total Validator(2011)Total Validator。www.totalvalidator.com2011 年 1 月 5 日访问
power mapper(2010)power mapper–网站测试和站点地图工具。Powermapper 软件。www.powermapper.com/2011 年 1 月 5 日访问
hazal-Massieux D(ed)(2011)W3C 语义数据提取器。万维网联盟。www.w3.org/2003/12/semantic-extractor.html2011 年 1 月 7 日访问
Sindice (2011) Sindice 网络数据检查员。http://inspector.sindice.com 辛迪斯有限公司。2011 年 9 月 20 日访问
W3C (2010)“有效”图标。在:标记验证器的帮助和常见问题中。万维网联盟。validator.w3.org/docs/help.html#icon2010 年 12 月 20 日访问
所有 W3C 验证图标的(2010)列表。万维网联盟。www.w3.org/QA/Tools/Icons2010 年 12 月 20 日访问
W3C (2011) W3C 图标库。万维网联盟。www.w3.org/Icons/2011 年 1 月 8 日访问
W3C (2011) W3C HTML5 标志。万维网联盟。www.w3.org/html/logo/2011 年 1 月 19 日访问
W3C (2008) W3C 网页内容可访问性指南 1.0 一致性标志。万维网联盟。www.w3.org/WAI/WCAG1-Conformance2011 年 1 月 8 日访问
W3C (2010) W3C 网页内容可访问性指南 2.0 一致性标志。万维网联盟。www.w3.org/WAI/WCAG2-Conformance2011 年 1 月 8 日访问
Jacobs I (2009) W3C 语义网标志和政策。万维网联盟。www.w3.org/2007/10/sw-logos.html2011 年 1 月 8 日访问
墨西拿 C，巴拉诺夫斯基 D，巴特尔梅 W (2010) Icons。微格式维基。微格式社区。microformats.org/wiki/icons2011 年 1 月 8 日访问
his software(2010)Cynthia 测试按钮指南——何时、为何以及如何使用。www.cynthiasays.com/org/cynthiatested.htm 软件公司。2011 年 2 月 4 日访问
页面排名检查器(2011)谷歌页面排名检查器。prchecker.info/2011 年 1 月 8 日访问

十五、最常见的错误

实现网站有效性需要考虑几个因素。代码要么是手工编写的，要么是自动生成的，错误是不可避免的。服务器设置也是如此。错误出现在标记、样式表、XML 文件、脚本等等中。通过分析和学习最常见的错误，可以消除或至少最小化其中的许多错误。因此，可以快速有效地识别、定位和纠正它们。

即使是最精心创建的网页也可能包含错误。在本章中，您将了解最常见的错误及其解决方案。了解它们是非常有益的，因为它们出现得相当频繁，学习如何纠正它们将减少纠正所需的时间，并减轻您的标准化工作。

常见发球失误

最常见的一个服务错误是将 XHTML 作为text/html来服务。多年来，web 浏览器处理 XHTML 标记就像处理 HTML 一样。这被称为“XHTML 的肮脏秘密”自结束标记和其他特定于 XHTML 的符号已经被忽略，XHTML 文档已经由 SGML 解析器而不是 XML 解析器呈现[1]。结果，XML 的所有有益特性都没有得到利用。

相比之下，现代浏览器支持正确的 MIME 类型。XHTML 文档应该作为application/xhtml+xml而不是text/html，正如在第四章中所讨论的。

常见标记错误

Web 标准化人员应该知道所有常见的标记错误，以便于识别、查找和纠正它们。不正确使用的元素、错误的文档结构、不正确关闭的标签、缺少alt属性、直接提供的&字符、忽略大小写、不唯一的标识符和拼错的关键字是最常见的标记错误。它们中的许多都被标记验证器清楚地指出，并且可以很容易地被纠正。验证器还提供了有用的纠正提示。但是，一些错误会导致其他几个错误。例如，一个部门缺少结束标记不仅会使文档在浏览器中折叠，而且会使嵌套变得不正确。因此，可能会发生这样的情况，一个验证器指出有 18 个错误的无效文档只有 2-3 个错误。所以，不要被最初的错误数量吓倒！

不正确使用的元素

作为一条黄金法则，必须特别注意消除标记中不必要的容器。例如，位于页面右侧带有文本“环绕”的图像可以直接样式化,而不是将它们放在浮动分区上。另一个例子是p标签，它应该用于段落容器而不是回车。看看清单 15-1 中显示的(非常糟糕的)例子。

***清单 15-1。*一种永远不应该使用的做法

This is a very bad practice

dating back to the early days

of the Web

unfortunately it is still in use

even if it has many drawbacks, e.g.,

illogical

hard to identify related content`

省略结束标签的技巧应该被遗忘。虽然它在 HTML 中是允许的，但它不是干净的代码，在 XHTML 中是无效的。具有基本(X)HTML 知识的初学者可能会认为应该将br元素添加到每一行的末尾，而不是错误地强制段落换行。他们错了。

网页内容应该是合乎逻辑的。前五行应该属于一个段落，后两行应该属于一个无序列表。前面的例子应该如清单 15-2 所示编写。

***清单 15-2。**清单 15-1 的正确标注为 *

This is a very bad practice dating back to the early days of the Web. Unfortunately it 外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
is still in use even if it has many drawbacks, e.g.,

Illogical
Hard to identify related content

文本宽度可以由外部样式表设置，以便达到与原始示例预期的相似(或完全相同)的效果。这完全取决于内容和出版需求。在这种情况下，清单 15-3 中的标记和清单 15-4 中显示的外部 CSS 文件中的适当样式将是一个标准的解决方案。

***清单 15-3。*更先进的解决方案

Illogical
Hard to identify related content

***清单 15-4。*清单 15-3 中的 CSS 规则集

.thinbox { width: 400px; height: 600px; font-size: 14px; }

结构不正确

使用不当的元素通常会违反 DOM 模型。应该提供必需的元素，并遵循嵌套规则。此外，应该通过以适当的方式使用正确的容器和元素来维护文档结构。看看清单 15-5 中的代码。

***清单 15-5。*列出没有结构或语义的项目(不正确)

`- first item

second item
third item
`

由于前面的行是列表中的项目，它们显然应该被收集到一个无序列表中。

***清单 15-6。**清单 15-5 的正确标注为 *

first item
second item
third item

由li元素提供的默认项目符号可以在 CSS 中更改为任意字符或图像(参见“样式列表”一节)。CSS 将呈现与结构完全分离；因此，任何元素都可以是任意样式的。

误用的表格

无表布局:网络标准化的说法。表格是用来组织数据的，不是用来控制布局的。为此，应该使用div元素。它们的位置、大小、颜色、层顺序、透明度和许多其他特征可以通过样式表设置(清单 15-8 中的而不是清单 15-7 中的)。

***清单 15-7。*误用桌子的碎片

***清单 15-8。*修正标记中表格数据的结构

Meaningful content in data cell

Content of other data cell

表格的位置由内容元素、文本和图像以及容器div元素决定。参数应该作为 CSS 规则集在与文档相关联的外部样式表中给出(参见“表格样式化”一节)。

非最佳代码长度

类似于第一章中讨论的“标签汤”，更具体的“div 汤”指的是除法的误用和过度使用(泽尔德曼称之为divi tis【2】)。清单 15-9 显示了一个例子。

***清单 15-9。*一个红利

The Latest News

主要问题是根本没有结构(即使它可能是有效的)。不必要的分歧应该消除。此外，这些名字太长了(尽管是描述性的)。它们应该保持在合理的范围内。

记住，在(X)HTML5 中，其他致力于结构化的元素应该作为主容器使用。

元素和属性错误

当使用另一个规范中定义的元素时，会出现总元素错误。应该根据文档类型使用元素。

不正确的嵌套元素会破坏文档结构，应该被删除。(X)HTML 文档中元素的位置和顺序不是任意的，应该满足第三章中讨论的嵌套规则的标准。

这两个错误都会导致 W3C 标记验证服务中出现消息“文档类型不允许此处有元素”。

类似的问题也与属性有关。W3C 标记验证服务给出错误消息“没有属性‘attrib _ name’”。允许属性的选择取决于所使用的文档类型。例如，在 XHTML 的过渡变体规范中定义的几个属性在严格的 XHTML 文档中是不允许的，详见第三章。类似地，XHTML 中也禁止几个 HTML 属性。样式属性应该在 CSS 中提供，而不是在标记中。应用特定于供应商的扩展如marginheight也会导致类似的问题。如果一个元素没有定义，它的属性也被认为是无效的。

结束标签错误

W3C 标记验证服务通过消息“省略了元素的结束标记，但其声明不允许这样做”清楚地指出了缺少的结束标记。W3C 标记验证服务将额外的(不必要的)结束标记标识为“未打开元素的结束标记”。

确保元素正确结束的最简单的方法之一是在打开后立即写结束标签，如清单 15-10 所示。

***清单 15-10。*在任何子元素之前提供结束标记

在提供结束标记之前，不应写入元素内容。这似乎是显而易见的，但是考虑到在开始和结束标记之间可能有数百行代码。此外，可能有几个相同的后续结束标记，即使使用缩进，它们的开始对也可能难以识别。

标识符

通常，在(X)HTML 标记中使用两种类型的标识符。自然地，主要用于样式化多个元素的class标识符可以在同一个文档中应用多次——而对于id属性则不是这样，它在整个文档中应该是惟一的(比如片段标识符)。

常见样式表错误

虽然 CSS 解析器有处理样式表错误的机制[3]，但是应该通过适当的创作来消除它们，并通过验证来确认。用不正确的属性和不存在的属性值编写声明是 CSS 中最常见的错误。

不存在的属性

最常见的 CSS 错误之一是应用了不存在的样式属性。W3C CSS 验证器用消息“属性不存在”清楚地指出了这些错误

CSS 命名约定不同于(X)HTML 标记中使用的命名约定。经验较少的人可能会键入一个符合逻辑的“应该是正确的”CSS 属性名例如，左边距可以用margin left属性设置，尽管left-margin(不存在)会更合理。即使看起来很简单，结果也是不正确的。如果有人不熟悉级联样式表的全部词汇，那么在应用它们之前，应该在适当的 CSS 规范中检查所有属性。另一个很好的例子是内容垂直集中的表格数据单元格。在 Web 的早期，许多样式都是直接在 HTML 属性上提供的，为此，valign属性被用在td元素上。然而，在 CSS 中，没有名为valign的属性。对应的属性有不同的名称:vertical-align。

不存在或使用错误的属性值

为了避免由不正确的 CSS 属性值导致的错误，应该知道允许的值以及关联的数据类型。此外，知道初始值(默认值)非常有用。例如，collapse、separate或inherit这三个属性值中的一个可以设置为border-collapse属性，用于设置表格边框是折叠成单个边框还是呈现分离状态。规则集border-collapse: yes;无法使用，因为属性值yes是非法的。因为这是一个可继承的属性，所以只有当继承的值不适合我们的目的并且需要被覆盖(或确保)时，才需要相应的规则集。

忽略继承

冗余经常出现在糟糕的 CSS 中。尽管这样的样式表可能是符合标准的，但是它们比需要的要长，使用更多的带宽，并且更难维护。只有适当考虑继承性，才能实现代码最优性。假设样式规则集出现在清单 15-11 中。

***清单 15-11。*冗余规则集(应优化)

`body {
  font-family: Verdana, Arial;
  font-size: 1.2em;
  color: #351801;
}

p {
  font-family: Verdana, Arial;
  font-size: 1.2em;
  color: #351801;
}

div {
  font-family: Verdana, Arial;
  font-size: 1.2em;
  color: #351801;
}`

之前的规则明显是多余的。一些开发人员会以清单 15-12 所示的形式编写它们。

***清单 15-12。*一个更好但仍然多余的解决方案

body, p, div { font-family: Verdana, Arial; font-size: 1.2em; color: #351801; }

由于浏览器为子元素(本例中的p和div)应用了与父元素(body)相同的样式，代码仍然是多余的，应该如清单 15-13 中的所示编写。

***清单 15-13。*正确答案

body { font-family: Verdana, Arial; font-size: 1.2em; color: #351801; }

换句话说，原始示例的第二个和第三个规则集是不需要的，应该删除。注意，在长的 CSS 文件中很难注意到这些相同的、冗余的规则，因为它们之间有数十个其他规则集。这就是为什么在一开始就考虑主要的 CSS 规则是很重要的，只有当继承的值不适合整体设计和布局时才覆盖这些规则。

后代选择器(也称为上下文选择器 4】)应该用于优化代码长度。检查[清单 15-14 中显示的标记和清单 15-15 中的 CSS 规则。

***清单 15-14。*符合标准但非最佳的标记(classis)

The is the main content of the site.

The second paragraph should look like the first one.

In fact, all paragraphs of the document have the same styles.

***清单 15-15。*符合标准但非最佳的造型规则

.maintext { margin-left: 15px; margin-right: 15px; margin-top: 10px; margin-bottom: 5px; font-size: 1.4em; color: #1d4c90; }

尽管标记和样式规则都以标准形式呈现，但代码远非最佳。这种类过度使用被称为class itis【5】。一个更简短、更容易理解的最佳解决方案可能是清单 15-16 中显示的标记，以及清单 15-17 中显示的 CSS 规则。

***清单 15-16。**清单 15-14 的正确标注为 *

The is the main content of the site.

The second paragraph should look like the first one.

In fact, all paragraphs of the document have the same styles.

***清单 15-17。*最优 CSS 规则

#main p { margin: 10px 15px 5px; font-size: 1.4em; color: #1d4c90; }

如果这不是页面的唯一部分，那么可以省略id属性，并且可以修改 CSS 规则集，以便应用于一般的p元素。

颜色误差

CSS 验证通常会导致颜色警告，表明前景色和背景色存在潜在问题。例如，如果在白色背景上使用非常浅的字体颜色，可能很难甚至不可能阅读内容。在这种情况下，W3C CSS 验证器会给出消息“在两种上下文中颜色和背景颜色相同”

但是，其中一些消息可能被视为误报，因为在某些情况下，可见性根本不是问题(透明或重叠层、背景图像上的文本等)。为了安全起见，即使页面的其他组件(例如，背景图像)无法下载，文本也必须保持可读。

不正确的位置

不正确的位置错误通常是由未正确关闭的规则集引起的。应该在 W3C CSS 验证服务错误消息“该元素不能出现在 CSS 2.1 的上下文中”所指示的行附近逐一检查它们。

透明背景

透明表面在整个网络中越来越受欢迎。一个div的透明度通常如清单 15-18 中的所示设置。

***清单 15-18。*一个典型但非标准的、依赖于浏览器的透明规则集

#transdiv { opacity: 0.7; filter: alpha(opacity=70); -moz-opacity: 0.7; -khtml-opacity: 0.7; }

在现代浏览器中，它运行良好。然而，当作为 CSS 2.1 进行验证时，验证器会给出错误。即使在 CSS3 中，也只有第一个(opacity)有效，它在 Firefox、Opera 和 Safari 中有效，但在 IE 中无效(它需要filter属性)。因此，通过移除最后三个属性可以获得有效性；然而，这个结果在 Internet Explorer 和其他浏览器的旧版本下不起作用。

一个有效的跨浏览器解决方案可以是透明的背景图像，如清单 15-19 中的所示。

***清单 15-19。*透明的 PNG 背景文件是一个可靠的解决方案

#transdiv { background-image: url('img/transpbg.png'); background-repeat: repeat; }

其他错误

不是所有的文档都可以被验证器检查。不正确的服务或临时服务器错误是最常见的原因。如果不提供自动文档类型检测或字符编码检测所需的数据，验证将无法执行或提供不可靠的结果。

常见新闻推送错误

有效的新闻提要通道应该是格式良好的，并且符合所有通用的 XML 标准。尽管如此，由于人为错误，手动更新的新闻提要中可能会出现一些错误。最常见的错误之一是日期不正确。如果发布日期早于更新日期，验证器会给出一个错误。这被称为不可信日期。必须注意应用适当的偏移，其误用会导致同样的问题。

常见脚本错误

脚本超出了标记验证器的范围。因此，必须格外小心，以确保正确性和适当的功能。应该确保网页保持可用，即使脚本由于任何原因无法执行。重要的是要记住，为脚本编写的替代内容不能被软件工具检查，它们的评估取决于人的决定。

常见的辅助功能错误

与标记或 CSS 错误(错误取决于所使用的语言版本)相反，可访问性错误是由所考虑的指南的版本和级别决定的。描述 WCAG 2.0 的技术和失败的 W3C 集团注释[6]中收集了对可访问性错误及其解决方案的全面概述(“失败的成功标准”)。最常见的可访问性错误可以总结如下:

缺少结构化标记或表格布局
传达重要信息的图像通过 CSS 嵌入
用户无法控制停止或暂停闪烁、滚动和自动播放声音文件或视频
声音效果和同步媒体缺少标题或标签
表单的用户指南不足
困难的导航和陷阱
期限
信息的表达完全依赖于颜色、形状、位置或图形
不可访问的自定义控件
非唯一标识符(不仅不可访问，而且无效)
缺少非文本内容和脚本的替代内容和详细描述
可能会因未请求的功能(如新窗口)而打扰用户的功能
文本不够清晰易读，字体太小，或者前景色和背景色或图像之间的对比度不够
缺少文档标题
文件名或占位符等替代文本缺失或不足
缺少标签
空白或控制间距，用于在纯文本或单词中创建多列
没有警告的自动表单提交
缺少或不正确的 tab 键顺序声明
表格中缺少标题单元格、标题和摘要
指向特定于设备的事件处理程序
非特定链接，如“点击此处”或“更多”

总结

本章列举了作为 web 开发人员在日常工作中可能会遇到的最常见的错误。现在你已经很清楚当你从头开始开发时如何消除它们，当你重新设计一个站点时如何改正它们。

通读本书后，您已经了解了从头开始编写有效标记的 web 标准和技术的重要性和好处。你知道如何识别标准，并把它们与未定型的规范区分开来。现在，您已经掌握了提供有意义的语义和机器可读的元数据、将标记限制为语义，以及在项目中实现完全的标准遵从性所需的所有技能。

参考文献

希克森 I (2009)将 XHTML 作为文本/html 发送被视为有害。伊恩·希克森。www.hixie.ch/advocacy/xhtml。2011 年 1 月 17 日访问
泽尔德曼 J，马科特 E (2010)迪维蒂斯的心碎。在:用网络标准设计，第 3 版。，新骑手，伯克利
博斯 B、切利克 T、希克森 I、维姆利 HW (eds) (2010)处理解析错误的规则。在:级联样式表级别 2 修订版 1 (CSS 2.1)规范中。万维网联盟。www.w3.org/TR/CSS21/syndata.html#parsing-errors。2010 年 10 月 13 日访问
Murphy C，Persson N (2009) HTML 和 CSS 网络标准解决方案——网络标准化者的方法。伯克利艾德的朋友
Zeldman J，Marcotte E(2010)classis:标记麻疹。在:用网络标准设计，第 3 版。新骑手，伯克利
库珀 M，里德 LG，范德黑登 G，考德威尔 B，齐索姆 W，斯拉丁 J(编辑)(2010)WCAG 2.0 的失败。WCAG 2.0 的技术。Web 内容可访问性指南 2.0 的技术和失败。万维网联盟。www.w3.org/TR/WCAG20-TECHS/failures.html。2011 年 3 月 3 日访问

上一篇：精通 HTML5、C

下一篇：精通 HTML5、C