内容


继承 Web 站点

让 Web 站点易于维护

如何轻松采用别人的 Web 站点并进行维护

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 继承 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 可以处理现有站点和上传的文件。
Validator 可以处理现有站点和上传的文件。

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

图 2. 验证摘要
Validator 指出您的页面(可能)符合哪一种规范
Validator 指出您的页面(可能)符合哪一种规范

在本例中,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 样式标记的问题。这些都不是 “乐意拥有” 的项目;它们是您希望其行为与预期一样的站点的本质。一个 bh1 标记位置不当或闭合,突然整个页面都变成了粗体……,用户成群结队离开您的站点。所以验证是将页面标记为 “可预测” 的一种方式。如果正确使用标记,则页面将结构良好且易于使用和浏览。

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

最后,针对有效的页面是否更容易被 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;
}

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

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

类似地,采取如下声明:

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
W3C CSS Validator 是其 Web 页面验证程序的补充
W3C CSS Validator 是其 Web 页面验证程序的补充
图 5. CSS 的成功验证
有效的 CSS 意味着所有规则都正确,语法完美。
有效的 CSS 意味着所有规则都正确,语法完美。

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

实现:添加 Doctype

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

添加 doctype 声明

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

图 6. Validator 确定 doctype
对于此 Web 页面,文档可能是 XHTML 1.0 Transitional
对于此 Web 页面,文档可能是 XHTML 1.0 Transitional

在本例中,页面最有可能是 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 站点不会让您头疼。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Web development, XML
ArticleID=311380
ArticleTitle=继承 Web 站点: 让 Web 站点易于维护
publish-date=06122008