如何使现有的Web 站点符合标准，易于维护－－－网站重构（一）

在完美的世界里，分配给您维护、改进和重新设计的每个 Web 站点都将由您来创建。不幸的是，在现实世界中，您却总是被迫采用别人设计或构造的站点。

新工作、新项目、新任务和新职责都伴随着风险。而且您可能有一个新老板、新办公室或一组新同事，但最让人感到胆怯的莫过于接手一个 Web 站点，这个 Web 站点现在由您来看护，而您根本不知道这个 Web 站点是如何整合的。通常 — 尤其是当您接管缺乏经验的 Web 设计师（或者更糟的是，是一个只会 “填充” 的人）的时候 — 您将要继承的站点是乱作一团的内容、演示文稿，甚至一些活动。当然，页面也很难看。如果没有 blink 标签，就一定会有 紊乱的样式，混杂着 CSS 样式的 font 标签，不完整的和滥用的 HTML 标签 …… 简直是一团乱麻。

谢天谢地，有一个逻辑方法可以将这类页面转化为完美的、容易维护的 Web 站点。这个包含两部分的系列将提供一些指导，将凌乱的页面转化为结构良好的、有条理的、可维护的代码。在第 1 部分中，您将学习如何让站点变得可维护。在 第 2 部分 中，您将组织站点的布局，提高其效率，并确保其在您掌控之中。

事实证明，一些经过事实检验的技术可以将这类任务变得易于管理，让您取得卓越的成效。这些技术还会确保您能够用最少的努力来重建站点，将大多数时间用于改进和维护站点。然后，如果以后您有机会更新甚至重新设计一个类似的站点，您可以从分段良好的 HTML 和 CSS 开始，而不是从令人费解和样式紊乱的 HTML 开始。

评估：您有什么？

处理别人的工作时，应该做的第一件事情是弄清楚自己到底有什么。也许直觉告诉您应该立即使用记事本（Windows® 中）和编辑器。但是，此刻所进行的更改将会使一切变得一团糟。您需要理解您正在处理什么，也许还需花几分钟时间 — 5 分钟或不超过 10 分钟 — 补充一些知识。

站点一览

使用 Web 浏览器打开站点。不要破坏 HTML 和 CSS，不用关心图像格式是 JPG 还是 GIF，只要打开站点就行了。使用记事本快速记下您看到的内容。但是（也是最困难的地方），只需关心重要的内容。不要关心 Internet Explorer 7 中的两个表之间的细微空白。相反，匆匆记下最初的印象：顶部的标题太过醒目。水平滚动太麻烦（实际上总是如此！）等等。

此处的关键不是使用许多步骤列出的需要对 HTML 所做的轻微改动。只需对其有一个总体印象。喜欢这个站点吗？讨厌这个站点吗？是不是内容太多了？图像太粗糙？您应该对如何处理站点的设计 形成一个大概的观点。您将处理一些实现，但一定要弄清楚大方向。

这个时候，您也希望没有 大量的设计工作要做。如果这个站点看起来非常完美，那么您的工作就轻松多了。这也是我让您在探究 HTML 和 CSS 之前 检查站点的原因。许多站点在谈到实现时都像是一场灾难，但站点本身看起来非常完美。如果先看到 HTML 和 CSS 纠结在一起的混乱局面，然后 查看站点，您可能会得出错误的结论，而进行不必要的重新设计 — 这都是因为站点的实现倒了您的胃口。首先查看站点，作出决定，然后钻研 HTML 和 CSS 中。

标准化

探究代码之前，您还需要执行一个步骤（虽然这无疑更接近实现）：验证您的 Web 页面。验证是查看您的 Web 页面是否是 HTML、XHTML，以及您的页面可能符合这些规范的哪个版本。通常，您还是想坚持使用 Web 页面的现有格式。

记住现在的目标是减少努力，因为您需要尽可能快速和轻松地让这个站点变得可维护。如果要重新设计站点，那么您可能希望转向您喜欢的方式。例如，如果您是一 位 XHTML 专家，您可能会将此站点更改为 XHTML，因为那是您的选择标准。但如果目标是效率，那么保持页面的当前格式可能 是您最好的选择。

弄清已经获得了什么

访问 W3C Markup Validator（请参见 参考资料）并为此站点提供自己站点的 URL（参见图 1）。

图 1. W3C Validator

Validator 将检查您的页面，并显示如图 2 所示的内容。

图 2. 验证摘要

在本例中，Validator 判断出您的页面属于哪种编码和 doctype，然后对其进行验证。

让 doctype 与页面一致

Validator 实际上能够最大限度地检测出您的页面是 什么，即使结果可能与此页面内的现有 doctype 不匹配。所以如果您已经获得声称是 XHTML 1.0 严格版的 doctype，而此页面实际上是 HTML 4.01 过渡版，Validator 将会告诉您这些。只需采用 Validator 猜想的结果，而不要试图与任意的 doctype 相匹配（也许是一个过分热心的 Web 设计者输入的？）。这是最有效的方法，可以让您快速获得可维护的有效站点。

Validator 也报告错误

除了判断您的页面是 什么，Validator 还会根据此判断报告错误。几乎每一种情况 — 尤其是如果您将要继承站点，同时也不能确定摆放在您面前的页面如何 — 您将得到错误（图 3 显示图 2 不可见的几种错误）。

图 3. Validation 错误

现在，我将再次给您一个难以遵循的忠告：不要开始修复这些错误！我知道，我知道……您迫切地想这样做。但事实是：如果 Web 站点乱作一团 — CSS 和 HTML 没有分开，到处都是换行符 (<br>) — 那么不管如何修复，您的一切努力工作都将改变。您已经 将 CSS 从 HTML 中分离出来了，那为什么现在要修复由此导致的错误呢？进行分离，然后 返回来处理验证问题。

此阶段的目标是确定自己的目标。如果您的页面定位于 XHTML 1.0，也许可以轻易将其返回到 XHTML 1.0。 我也做一个假设：设计者也许选择 XHTML 1.0 有一定的原因，即使您不知道原因，也一定要坚持此决定。

如果您的站点返回到 HTML 4.01 过渡版 — 这基本上是最松散的可能选择 — 那么不管怎么样您都是好的，因为您要进入的是一个低门栏。此处的想法是找到通向坚固站点的最短的可能路径 — 不管是在设计还是在实现上 — 满足原始设计师给定的任何要求。有时您不知道这些要求是什么，因此验证是对其进行逆向工程的一种方式。

但是我有 1,000 页！

迄今为止，我们的假设是您通过 Validator 手动运行站点中的每个页面。本质上，这是确保捕获每个页面上的每个错误的最佳 方法，并给予每个页面适当的关注。当处理了前几个页面之后，您通常会更改应用于整个站点（例如，可以通过大量的搜索和替换重新设计一个标题区段来），从而使后面的页面更容易处理。

然而，因为重点在于效率，所以可以选择批处理验证。在这些情况下，您将需要超越 W3C Validator，使用像 WDG HTML Validator（允许在文本框中输入多个 URL — 更好，尽管不是最好）或者 CSE HTML Validator（一个便宜的批处理程序）这样的工具。（在

为什么要验证？

如果您像 Web 开发领域的其余大部分人一样，验证充其量只是有点讨厌，最坏也不过是一场情节丰富的噩梦。第一次通过 Validator 运行页面时，会看到数百个的红色阴影的错误消息，简直就是势不可挡。但您可以从验证中获得一些好处，这些好处使您对页面的验证非常值得。

第一个且最重要的是，有效页面将会正确显示。无效页面通常缺少结束标记，HTML 标记嵌套不正确，甚至 CSS 样式标记的问题。这些都不是 “乐意拥有” 的项目；它们是您希望其行为与预期一样的站点的本质。一个 b 或 h1 标记位置不当或闭合，突然整个页面都变成了粗体……，用户成群结队离开您的站点。所以验证是将页面标记为 “可预测” 的一种方式。如果正确使用标记，则页面将结构良好且易于使用和浏览。

此外，验证还提供了一个基准功能，可以始终检查页面的更改和升级。如果您对页面进行验证，然后它停止 验证，那么您就会知道所做的更改确实破坏了站点的结构，甚至表示。 因此验证可以作为一种检查 — 有点像每次更改代码之后进行编译一样。如果编译（或验证）失败，那么一定有一些事情出错了。

最后，针对有效的页面是否更容易被 Google、Yahoo! 和 MSN 等搜索引擎索引，存在着激烈的争论。这些搜索引擎使用的算法的都是高度保密的，并不断更改，因此您将发现一些资料说验证很重要，然后说它并不重要，接着说 没必要，但会增加您的搜索分数或索引。总体来说，除了每个公司的极少数人（我们不知道）之外，确定无疑的是结构和表示正确（验证帮助做的事情）的页面将会 被更多的访问、更多的索引，最终在任何搜索顺序中的等级都会更高。

实现：清理 CSS

这时候，您应该对站点的总体设计有了比较贴切的感觉，而且对站点的设计规范（HTML、XHTML 等）有一定的了解。现在，终于到了更改站点本身的时候了。

提取 CSS

不管您的目标是 HTML 过渡版、HTML 严格版、XHTML 过渡版，还是 XHTML 严格版，都需要将样式拉入外部 CSS 样式表中。如果您已经将显示和样式混合在内容中，则无法保持一个易于维护的一致的站点。

Web 上有不计其数的文章介绍分割 CSS 和 HTML，所以我不再详细介绍（请参见 参考资料 一节中的链接）。但是，您应该注意下列事项：

• 这应该是一个非常机械的 过程。您不尝试改进页面的外观。您仅尝试从 HTML 中获得 CSS。
• 不要担心优化和压缩您的 CSS 规则。只从 HTML 中获得它。您将在下一步骤中对规则进行一些处理。
• 您仍然不用担心验证，所以不必在意 <br /> 和未闭合的 <p> 标记。您将彻底解决这些问题，但不是现在。

完成之后，HTML 的顶部应大致如下所示：

<![CDATA[
  <head>
    <title>The Starbuzz Bean Machine</title>
    <link rel="stylesheet" type="text/css" href="starbuzz.css" />
    <link rel="stylesheet" type="text/css" href="styledform.css" />
  </head>]]>

本例具有多个样式表。这是可选的，但如果您已经获得站点的特定区域以及核心外观，我建议您这样做。

优化 CSS

获得 HTML 的所有样式之后，应该具有一个或多个 CSS 样式表。（是的，我知道 CSS 样式表是多余的 — 级联样式表。但我不知道如何编写，所以享受这个幽默吧。） 获取其中每一个，逐步进行处理。如果具有如下所示的内容：

h1 {
  color: #933;
  font: Georgia;
}

h2 {
  color: #933;
  font: Georgia;
}

—则考虑将其压缩为如下：

h1, h2 {
  color: #933;
  font: Georgia;
}

一点都不惊奇，是不是？但它只是看起来简单。考虑更现实的情况，h1 和 h2 语句是分隔在大量 CSS 样式表中的数百行。然后，更改其中一个，但另一个标题中的字体是错误的。

处理这种情况的一个办法是依字母顺序排列您的声明。是的，这非常痛苦，但它将确保 h1 和 h2 最终结合，table、td 和 tr 最终互相结合。将相似元素放在一起，然后压缩样式，这样做非常值得。

类似地，采取如下声明：

h1 {
  color: #933;
  font: 16px Georgia;
}

h2 {
  color: #933;
  font: 12px Georgia;
}

您仍然应该消除公用元素，并将其集中起来：

h1, h2 {
  color: #933;
  font: Georgia;
}

h1 {
  font-size: 16px;
}

h2 {
  font-size: 12px;
}

尽管此处仍有两个声明，但您已经在单个位置（在本例中是 h1）获得通用性。

处理所有 CSS 样式表，并确保尽可能地将其调优。压缩规则，以减少重复项，并尽量剔除规则。例如，如果每个高级元素具有 Georgia 字体设置，则考虑将此规则放入 body 部分中，并移除所有单个规则。越简单越好。

验证 CSS

这是可选步骤，但将会真正减轻您的负担。准备好 CSS 之后，对其进行验证（参见图 4）（在 参考资料 一节中可以找到 CSS Validator 的链接）。与页面验证程序一样，CSS Validator 将确保 CSS 与预期一样。无语法错误，无输入错误（参见图 5）。

图 4. CSS Validator


图 5. CSS 的成功验证

CSS 验证在技术上没有确保整个页面有效那么重要。事实上，有效的 HTML（或 XHTML）Web 页面可以具有无效 的 CSS（参见图）。但是，CSS 验证将确保一切都很完美和干净，您的手动工作将确保您的 CSS 得到优化。

实现：添加 Doctype

现在再次验证您的站点。应该会看到许多 错误都消失了，而且您的 CSS 已经从 HTML 中隔离（清理和验证）。现在，不要忘记归档您所作的一切。如果没有 doctype，则需要添加一个，以及字符编码。这些将您的站点更容易维护。

添加 doctype 声明

从 Validator 获得响应之后，集中处理 doctype（参见图 6）。这将告诉您 Web 页面的目标版本 — 基于 Validator 的最佳猜测。

图 6. Validator 确定 doctype

在本例中，页面最有可能是 XHTML 1.0 过渡版。这可能不同于先前运行验证时的文档，但很可能相同（CSS 通常不影响 HTML 与 XHTML 比较）。

但是现在，验证器将猜测这一点（在大多数情况下）。您应该添加 doctype 声明。打开 HTML，在顶部添加如下内容：

<![CDATA[
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
                      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<!-- Rest of your HTML -->
]]>

本例适用于 XHTML 1.0 过渡版。对于 XHTML 1.0 严格版，您将使用如下内容：

<![CDATA[
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
]]>

对于 HTML 4.01 过渡版，将使用如下内容：

<![CDATA[
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
<html>
]]>

对于 HTML 4.01 严格版，应使用如下内容：

<![CDATA[
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
]]>

注意，使用 HTML doctype，不需要 html 元素上的 xmlns 属性，这是特定于 XHTML 的（它是一个 XML 名称空间，但这是另一篇文章的主题。）

所有这些都向 Validator — 以及其他任何可能继承您的 Web 站点的人 — 声明文档的目标是什么。您可以重新运行 Validator，您应该不会注意到差别，除非您选择的 doctype 与 Validator 认为的您的页面目标不同。那样的话，您可能看到更多（或更少）的错误。

针对 XHTML 用户：内容类型

如果使用过一种 XHTML doctype，您将只需再进行一个简单步骤。您需要添加一个 meta 标记，告诉文档您的内容类型。如下所示：

<![CDATA[
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>]]>
  	<b>
		<meta http-equiv="Content-Type" content="text/html; charset=UTF=8" />
	</b>
<![CDATA[
  <title>My Page Title</title>
</head>
 <!-- etc. -->
]]>

这确保了 Validator（以及其他程序，比如符合 XHTML 的 Web 浏览器）在读取您的内容时知道预期的内容。还可以使用 HTML 页面添加内容类型，尽管这只是严格的 HTML 4.01 所需的。（注意，在 HTML 中，应该在 meta 标记末尾去掉斜杠；这是 XHTML 的要求。）

验证站点

分离 CSS 和 HTML，了解要使用的 HTML 或 XHTML、文档类型和内容类型，您应该清理任何滞留的错误了。

简单错误

再次验证 — 现在您已经确定了目标 — 并开始处理您的错误。图 7 显示了可能发现的典型问题。

图 7. 一次处理一个错误

这很容易修复。此页面的 form 元素缺少 action 属性。添加此属性，错误将消失。太简单了，对不对？

一次修复一个错误

修复第一个错误之后，再次验证。这稍微有点烦人 — 而且将花费一些时间，修复错误，验证，修复另一个错误，等等 — 但这是使用验证程序的惟一 有效的方式。许多错误导致更多 错误，大多数时候，您修复一个错误，结果会修复 9 个或 10 个其他的错误。

我建议您准备好您的 HTML 编辑器和两个浏览器窗口（或选项卡）：您的站点和 Validator。您可以进行修复，将文件保存在编辑器中，然后刷新两个浏览器选项卡，再次查看站点和更新的验证报告。

保存原始资料（baseline）并将其锁定

具有有效的页面之后，需要将此版本锁定。备份此版本，并将其复制到 ZIP 驱动器和 USB 设备上（只需确保它存在于几个位置并清楚标记）。这就为您的站点建立了原始资料。

现在，不管何时进行任何更改，都应该能够进行下列事项：

• 确保页面仍然有效。因为开始时是有效的，所以您可以逐步处理，而不是同时处理旧代码和新代码。
• 确保页面看起来良好。再次，使用原始资料，很容易孤立任何问题。
• 如果陷入灾难之中，您不必重复本文介绍的一切。您可以从一个有效的、自我归档的版本开始。

何时应该进行改进？

本文所有篇幅都在讨论无聊乏味的任务 — 几乎为讨论您所做的一切会如何影响到 Web 站点的实际外观。这是因为此处的目标在于处理一个您必须维护的站点，一个之前您一点都不了解的站点。

在这些情况下，您通常不会想到进行改进。您希望减低开销。如果您以后 想继续并进行设计更改，那么欢迎您。但现在仅仅获得了一个好的开端，而没有尝试将设计与清理 CSS 混在一起，并弄清楚是否要编写严格的 XHTML、HTML 或其他任何东西。

如果您不 希望改进站点，那么您已经达到目的了。您已经有了一个有效的站点。但更重要的是，您让这个站点变得易于维护，而且如果出现问题的话，隔离并解决这些问题将十分简单。

结束语

显而易见，处理别人的 Web 站点没有多少吸引力。您不得不接受他们的设计选择、他们的（可能不好的）HTML 和 CSS、他们的颜色选择和标记选择以及结构。然后，关键在于可以花费尽量少的时间进行常规维护，从而允许您将时间花费在重新设计站点或开发您真正 喜欢的其他项目上。

实现此目标的最佳方法是，找到给定站点与稳定的可理解的站点之间的最短路径。这意味着弄清楚您具备什么，确定您需要实现什么，然后采取简单的步骤来实现。本文展示了一种方法，它不会让您继承的站点变为设计冠军，但它允许您利用 设计冠军。保留站点的现有格式 — HTML 或 XHTML，严格或过渡 — 使用成熟的 CSS 和 HTML 实现，将为您节省大量的时间，不管是中期还是长期。

在本文的 第二部分 中，我将介绍速度、可访问性和组织。尽管都是基于简单维护的目标，但有许多不同的注意事项。通过少量的工作，确保您在进行很酷的新设计时，您的 Web 站点不会让您头疼。