如果你阅读了本系列的第一篇和第二篇文章，现在应当开始进入渐进增强的思维模式了。本文讨论如何将渐进增强的哲学应用到客户端脚本。你将很快看到，这涉及两个方面：约束与规划。

聪明地支配能力

也许你已经听说过“权力腐败”。这个词能引发很多联想，不过根据我们的用意，还是继续将其看成两个简单的词吧。JavaScript是一个能力强大到让人难以置信的工具，很长一段时间它的威力让web一团糟。它给web冲浪者扔下路障、错误信息还有太多的弹出窗口。对JavaScript的极大误解，可能导致了它的滥用，并使其在实践中更像一门黑色艺术。

JavaScript不仅造成的伤害多过好处，它还变得难以控制。实质上，它就像一辆破自行车，除了铃儿不响，其它哪儿都响。因为晦涩并经常私下开发的代码分支迅速繁殖，维护也是一场噩梦。

当年，JavaScript只能是丑陋的：浏览器还需对适当标准提供支持，而开发者们正忙于在HTML中书写像意大利面条一般杂乱的代码。为了完成跨浏览器兼容的任何事情，甚至简单得像图像翻转，JavaScript也必须解决很多令人头疼的问题。

谢天谢地，我们现在的处境好多了，终于能使得JavaScript代码干净许多。然而，我们必须尊重JavaScript的能力并且表现得负责。我们需要关注JavaScript如何使用，或许更需要关注JavaScript能做什么。我们需要学会约束。渐进增强能够帮助我们做到这一点，因为它让我们关注内容并且从内容开始构建。

建立基线

使用渐进增强，我们在可用代码的基础上构建站点。JavaScript的关键理念需要牢记于心：即便没有客户端脚本，任何用户需要用来理解页面意图的内容也应当存在于该页面中。这是第一课。

例如：上面讨论的内容可能是一个售出产品的对照表格。如果站点的需求指明在点击列头时，需要对数据排序，你可能会考虑通过Ajax来将数据加载到页面中，这样发送简短的请求就可以在服务器端进行排序。看起来很美妙，不是吗？

错了。

当禁用JavaScript的潜在用户访问该页面时，会发生什么？如果内容通过JavaScript加载到页面，这些用户根本访问不到内容，即便在没有排序的状态。如果他们连产品都看不见，你认为他们达成交易的可能性还有多大呢？

上面的场景还没有考虑到搜索的影响。搜索引擎爬虫不会执行JavaScript，因此如果使用JavaScript来将内容加载到页面，搜索引擎将永远不会读取或索引你的内容。如果产品信息不能在Google, Microsoft或Yahoo中索引和搜索到，你将丧失多少潜在客户？

如果带着渐进增强的想法，为了完成上面同样的需求，可以将基本的表格包含在HTML标记中。大部分情况下依旧需要后台程序来生成，但是需要直接嵌入在页面中而不是通过Ajax来加载。你仍然需要编写脚本，在DOM中找到表格，使其具有交互性，生成排序链接，并在它们的onclick事件中绑定Ajax调用，最后打造出一个可排序的表格。

用这种方式完成挑战，不但满足了需求，还为搜索引擎爬虫和没有JavaScript的用户提供了一个“低保真”的体验。

再考虑远些，甚至还可以给表格头部手动添加一些排序链接，通过传递排序表格的相应参数，让它们能刷新页面。这使得没有JS的用户也能重新对数据排序，虽然响应速度稍微慢些，但仍然是功能齐全的“高保真”体验。

在脚本中加入些简单的小调整，还可以通过hijack技术让上面的排序链接依旧像以前一样执行Ajax请求，将最好的体验带来大部分有能力的用户。最后，你拥有了一个渐进增强实战的完美例子。

到这里，已经拥有了对JavaScript渐进增强的基本理解，我们能够讨论一些可以立刻使用的技巧了。

让脚本可控

有效集成渐进增强的一个关键是为脚本的管理建立规划。为了做到这一点，首先要熟悉“无侵入式JavaScript”的概念。无侵入式JavaScript是渐进增强在客户端脚本世界的基础。

“做到无侵入”最明显的办法是去掉所有行内的事件处理器，因为它们可以很简单地通过DOM来注册：

<a href="http://msdn.com" onclick="return newWin(this.href);">

接下来，将所有脚本移动到外链的文件中，而不是嵌入在script元素中：

<script type="text/javascript">
  // my script
</script>
<script type="text/javascript" src="myscript.js"></script>

这可以让维护变得更轻松同时让你拥有一些代码库。（坦率地说，这两个变化可能需要不少工作量，因为这么多所见即所得编辑器和web应用程序开发框架生成可怕的侵入式JavaScript代码。值得庆幸的是，很多系统已经有补丁和插件用来克服它们的坏习惯。）

要使得脚本无侵入，接下来的步骤是决定何时以及如何包含它们。在最简单的层次上，这意味着检查，调用方法前先测试是否支持此方法，以确保脚本能在用户浏览器上运行：

if( document.getElementById ){
  scriptUsingGetElementById();
}

你可能还想测试所有需要的对象，甚至还想测试用作脚本钩子的标识元素是否存在。对使用的每个脚本都按这个流程走，可以创建一个点菜式的交互体验，只有那些用户浏览器可以处理以及当前页面需要的脚本会被执行。

关于无侵入式JavaScript的更多介绍，请再次访问Jeremy Keith’s关于此议题的文章。

保持样式分离

JavaScript不存在于真空中。就如同应当让脚本和标记保持一定的分离（如上所述），也应当让脚本和样式保持一定的分离。

总的来说，当你在DOM中创建或操作元素时，必须停止添加行内样式，而应该应用类名，该类存在于全局样式表或某个脚本特定的样式表中：

var el = document.getElementById( 'message' );
el.style.color = '#f00';
el.style.backgroundColor = '#ffcfcf';
el.className = 'highlighted';

如果脚本需要很多样式来激活交互，采用脚本特定的样式表是个很不错的选择。在使用样式表的脚本中设置这些样式表，可以使得它们的维护能独立于站点上的其它样式表。这还能使得仅在脚本执行时才链接这些样式表，这样，对于没有使用该脚本或不支持该脚本的浏览器中的页面，能减少下载次数。

如果你决定将样式嵌入在某个主要样式表中，一定要采用上面的方法来给元素添加样式，以使得这些样式仅在脚本成功运行时才会被应用。

关于样式和脚本分离的更多信息，请阅读Scroll杂志首刊的这篇文章（目前只有印刷版本）。

取得进步

我们回顾了在JavaScript中实现渐进增强所需要的心态，以及做到渐进增强的若干技术。我们还接触到了无侵入式脚本的概念，并学会了少许技巧来管理CSS和JavaScript的内部关系。

本文完成了我们介绍性的系列文章，该系列关注渐进增强以及在CSS和JavaScript中实现渐进增强的方法。希望能引发你的思考并激励你开始在工作流程中使用渐进增强。

本系列上一篇涵盖了渐进增强的基本概念，现在我们来讨论如何应用。有多种方式可以将渐进增强融入到层叠样式表（Cascading Style Sheets, 简称CSS）的工作中，本文将讨论其中比较成功的一些，并考虑采用其它方式来逐步增强你的站点。

样式表的组织

如何在文档中引入样式表，很多Web设计者和开发者并没有想太多，但这其实是一门艺术。使用正确的方法，可以立即获得渐进增强的很多好处。

使用多个样式表

对样式进行稍许拆分可以带来很多好处。显而易见，超过1500行的样式表是有点难以维护的，将其拆分成多个样式表，可以改进工作流程（并节省你的精力）。还有一个好处很少提及：有助于在目标媒介类型（译注：指计算机、打印机、电视、手机等各种媒介类型）上获取更一致的呈现效果。

main.css文件包含了站点的所有样式规则，考虑将其拆分成包含版式、布局和颜色的独立样式表，相应地命名为：type.css, layout.css, color.css.

（图示：如何将单个样式表拆分成多个相关的样式表）

一旦完成了上面的分离，就可以使用一点神奇的小手段来给过时的浏览器（比如IE5/Mac）和很多对CSS布局缺乏有力支持的浏览器自动提供“低保真”的体验。怎么做呢？这完全取决你如何引入文件。假设通过link元素来引入main.css:

<link rel="stylesheet" type="text/css" href="main.css" />

首先，将上面一行引用拆分成三个相关的样式表：

<link rel="stylesheet" type="text/css" href="type.css" />
<link rel="stylesheet" type="text/css" href="layout.css" />
<link rel="stylesheet" type="text/css" href="color.css" />

在过去，很多开发者将media的值设为”screen”或”projection”, 以使得布局样式在Netscape 4.x上彻底失效（译注：Netscape 4.x不支持浮动和定位等复杂布局）。然而，有更好的解决方法。在详细讲解这个方法前，我们先来看看可选媒介类型（Alternate Media Types）。

可选媒介类型

渐进增强主要关注内容，我们要将“增强”的体验带到所有支持内容显示的设备上。因此需要考虑浏览器之外的设备，比如打印和移动设备就很重要。

糟糕地是，移动设备市场依旧四分五裂而且不成熟（不要天真地认为所有手持浏览器都会渲染目标为“screen”的媒介类型样式）。结果，用渐进增强的方式来处理所有媒介的细节讨论，如果不写成一本书的话，也得用上好多篇幅。然而请别沮丧：在移动世界里，差异正开始统一起来，并且一些非常聪明的人正开始将资源放在一起以帮助我们开发。不过，为了节约时间和节省精力，我们将集中于打印设备上。

通常，我们需要使用另一个link元素来添加打印样式：

<link rel="stylesheet" type="text/css" media="print" href="print.css" />

按照惯例，上面这个样式表包含所有打印相关的规则，包括版式和颜色规则。特别是版式，样式表中的规则大部分很可能拷贝自main.css. 也就是说，这造成了很多重复代码。

可以看出从布局样式中拆分出版式和颜色样式的好处了：在打印样式表中，我们不再需要那些重复的规则了。除此之外，可以使用另一个组织上的小技巧来改进站点的适用性，以及针对有问题的浏览器隐藏某些布局样式。

回顾下我们的样式表，考虑以下代码：

<link rel="stylesheet" type="text/css" href="type.css" />
<link rel="stylesheet" type="text/css" href="layout.css" />
<link rel="stylesheet" type="text/css" href="color.css" />

我们没有声明媒介类型，因此 Netscape 4.x 会读取这三个文件中的所有样式。但是，Netscape浏览器能理解最基本的CSS, 我们可以利用这一点。通过将layout.css包含的所有样式移动到新的样式表——适当的取名为screen.css, 我们可以进一步组织样式。最后，将layout.css中的内容更新为引入screen.css, 这样，NS4.x和它的同族浏览器们就再也聪明不起来了（因为它们不理解 @import指令）。（译注：作者这里说的是将所有layout.css中的内容都移动到screen.css中，然后在layout.css中通过@import引入screen.css. 我觉得最好的做法应该是在layout.css中保留最基本的NS4.x也可以理解的布局样式，而将其它高级布局样式移动到screen.css中。）

@import 'screen.css';

还有一些改进的余地——应该声明样式表所针对的媒介，我们通过给@import声明添加媒介类型来做到这点：

@import 'screen.css' screen;

问题是IE7及以下浏览器不理解这种语法从而忽略上面的样式表，如果想给这些浏览器提供上面的样式（这是经常期望的），可以很简单地使用条件注释来做到，这将在下文阐述。如果你拥有鹰一般利锐的眼睛，可能已经注意到在样式表名称的两边使用了单引号（’）来替代双引号（”），这个小技巧可以让IE5/Mac忽略样式表。IE5/Mac的CSS布局能力非常弱（特别是对浮动和定位的支持），对它们隐藏布局规则是完全可接受的。毕竟，它们依旧能获取颜色和版式信息，这在某些情况下已经够用了。

采用相同的技术，可以导入print.css文件（和你猜想的一样，包含打印布局的特定规则）。

@import 'screen.css' screen;
@import 'print.css' print;

现在我们不仅拥有了组织得很漂亮的样式表，我们还拥有了一套逐步增强站点设计的有效方法。

（图示：多个样式表间的相互关系以及将它们应用到文档的方法）

现在讨论值一千万美元的问题：如何处理IE6？

对很多伙计来说，Internet Explorer 6 是一个新的 Netscape 4 ——所有人都想让它滚蛋。

我们略过对IE6问题的喋喋不休。IE6的问题已经有了很好的文档总结，并且，老实说，解决起来也并不是那么困难。而且，IE7的采纳相当快速（特别是在消费市场），同时IE8也已经在公测了。这意味着某一天，我们可以真正地对老态龙钟的IE6说拜拜。

不管是有意还是无意，微软在推出IE5时，为渐进增强提供了一个好工具：条件注释。这些巧妙的逻辑片段（在所有其它浏览器中都降级为HTML注释（译注：其它浏览器把IE的条件注释理解为纯粹的HTML注释，不起任何作用））不仅允许某些标记代码片段只作用于IE，还允许这些代码片段只作用于IE的特定版本。

作为有Web标准意识的开发者，我们始终应该首先在大部分现有的兼容标准的浏览器上测试我们的设计，然后再为那些稍作细微修改就能回到正轨的浏览器提供补丁。每个人的工作流程都不同，但我发现最好用一套标准的文件来开始每个项目。我的基本套件包括以下文件：

• type.css
• layout.css
• screen.css
• print.css
• color.css

然后，根据项目的需求，添加针对特定浏览器的CSS文件来包含那些“细微修改”。在现在的大部分项目中，这些文件是ie7.css和ie6.css. 如果项目要求支持IE6之前的版本，我也会为其创建相应的文件（比如ie5.5.css等等）。将这些文件放在恰当的位置后，我开始将样式规则添加到合适的样式表中。

我的CSS测试都是从Mozilla Firefox中开始，因为我的大部分CSS都是用Firefox的CSS编辑侧栏来编写的。一旦在Firefox中完成了页面设计，我立刻开启其它浏览器来测试查看。大部分表现很完美，因为他们遵守了Web标准。接着打开IE7来测试。大部分情况下也没多少问题，偶尔需要触发hasLayout或者修正另一些布局上的小错误。我没有将这些修正补丁写入到基本套件的样式表文件中，而是添加到ie7.css中，并且在文档的HEAD中通过条件注释来引入：

<!-- [if lte IE 7]>
<link rel="stylesheet" type="text/css" href="ie7.css" />
<[endif]-->

上面的条件注释使得IE7及其以下版本（译注：lte是less than or equal的缩写）能识别引入的样式。因此，当用IE7浏览页面时，将获取这些补丁。但是如果用的是新版本的IE——可能已经修复这些问题，比如IE8抛弃了hasLayout从而不再有这些问题——将忽略这些样式。另一方面，使用IE6可以获取到这些样式。这是很好的，因为在IE7中的渲染错误往往也存在于IE6中。上文中已经提及，IE7及其以下版本无法理解带媒介类型的@import，通过这种方式引入screen.css对IE7及其以下版本是无效的。因此，还需要在ie7.css文件的顶部添加不带媒介类型的@import语句来引入screen.css.

一旦为IE7添加完补丁，我会打开IE6, 看看是否需要随手打些补丁。如果确实需要，我会给文档添加另一个条件注释，引入ie6.css:

<!-- [if lte IE 7]>
<link rel="stylesheet" type="text/css" href="ie7.css" />
<[endif]-->
<!-- [if lte IE 6]>
<link rel="stylesheet" type="text/css" href="ie6.css" />
<[endif]-->

接着，简单地将IE6需要的补丁添加到对应的样式表中，这些样式表将被IE7忽略，但是会依旧往下影响到IE5.5等版本。

通过这种方式使用条件注释，可以很轻松的管理项目中的目标浏览器，并使得CSS补丁文件保持独立自由。

其它考虑

CSS渐进增强并不局限于如何将样式表与文档关联起来，还可以应用在如何编写CSS上。

例如，考虑生成的内容（译注：比如用:after伪类生成的内容）。并非所有浏览器都支持，但这是一个很好的方法：可以用来添加一些额外的设计或文本。对于页面的可用性来说，这不是必须的，但这能提供一些视觉或其它方面上的增强。

拿简单的联系表单来举个例子：

（图示：此例中使用的HTML表单（代码将在下面给出））

当编写上面的HTML代码时，很可能会自然地将冒号（:）写在label元素里。为什么要这样做？真的给label元素添加了内容吗？并没有。这样做的目的是给用户提供额外的视觉线索，对label元素来说，这是多余的，应当去掉：

<form id="contact-form" action="#" method="post">
  <fieldset>
    <legend>Contact Us</legend>
    <p>Send us a message. All fields are required.</p>

    <ol>
      <li>
        <label for="contact-name">Name</label>
        <input type="text" id="contact-name" name="name" />
      </li>

      <li>
        <label for="contact-email">Email</label>
        <input type="text" id="contact-email" name="email" />
      </li>
      <li>

        <label for="contact-message">Message</label>
        <textarea id="contact-message" name="message" rows="4" »
        cols="30"></textarea>
      </li>
    </ol>
    <button type="submit">Send It</button>

  </fieldset>
</form>

通过生成内容来将冒号添加回文档，这是一种更完美合适的方式：

label:after {
    content: ":";
}

用这种方式来编写表单，给了我们灵活性：当需要从整个站点移除装饰字符时，只要简单的编辑CSS文件，而不需要去寻找每一个表单（虽然我们曾经知道在哪）。这个技巧也能够很好降级，因为没有冒号时，表单并不会被渲染得无法使用——这是渐进增强的一个绝佳例子。

也许你已经发现，使用高级CSS选择符（译注：selector, 也有译为选择器的，但我觉得选择符更能体现本意，比如operator翻译成运算符，而不是运算器），可以将特定的样式附加到更多高级浏览器上，这有助于逐步增强站点。一个很好的例子是属性选择符，在IE6及其同一时代以及更早的浏览器中不能被理解（因此也就被忽略了）。Egor Kloos很漂亮地运用了这个概念，在CSS禅意花园（CSS Zen Garden）上提交了名为”双双”（Gemination）的作品：

（图示：Egor Kloos的CSS禅意花园作品（“双双”）在标准浏览器和IE6中的呈现对比）

他是怎样做到的？下面是略加修改的示例代码：

/* <= IE 6 */
body {
  margin: 0;
  text-align: center;
  background: #600 none;
}

/* IE 7, Mozilla, Safari, Opera */
body[id=css-zen-garden] {
  margin: 100px 0 0;
  padding: 0;
  text-align: center;
  background: transparent url(squidback.gif);
}

差异很明显，并且非常漂亮地说明了渐进增强如何应用在CSS中。

类似地，Andy Clarke的站点上也有些关于IE6的小玩意。通过使用IE的滤镜以及加入一些条件注释，Andy成功地去除了站点上的所有颜色，并提供了一些可替换的图片，这构成了一个真实的“低保真”体验。

（图示：Andy Clark的站点在标准浏览器和IE6上的对比）

上面的图片灰色技术是这样的：在条件注释添加的针对IE6（及其以下）的样式表中，添加以下声明：

/* =img for Internet Explorer < 6 */
img {
  filter: gray;
}

尽管上面这两个例子可能包含了过多日常工作中的运用不到的技巧，但它们非常棒地用事实说明了一个概念：如何在实践中应用CSS渐进增强。

总结

正如我们讨论过的，有多种方式可以将CSS渐进增强应用到站点上。最简单也可能是最好的一种方式是，组织好样式表并认真考虑如何将样式表链入文档。一旦理解了条件注释，处理IE的特定问题也将是轻而易举的事。如果对如何选用选择符以及使用它们的场景了然于胸，还能在CSS中完成更多小粒度的调整。

用这些知识武装起来，在通往渐进增强专家的路上你将平坦前行。下一篇中我们再聚，讨论JavaScript渐进增强。

• 浮动 float
• 负边距 negative margin
• 相对定位 relative position

这是实现布局的三个最基本的原子技术。只要巧妙组合，并加以灵活运用，就能“拼”出各种布局的实现方案。

尝试之路

考虑以下DOM结构：

<div id="page">
    <div id="hd"></div>
    <div id="bd">
        <div class="main"></div>
        <div class="sub"></div>
        <div class="extra"></div>
    </div>
   <div id="ft"></div>
</div>

利用浮动元素的负边距来定位：

    .main {
        float: left;
        width: 100%;
    }
    .sub {
        float: left;
        width: 190px;
        margin-left: -100%;
    }
    .extra {
        float: left;
        width: 190px;
        margin-left: -190px;
    }

这样我们得到了第一个尝试页面 pe_layout_example1.html.
可以看出，通过简单的负边距，已经让sub和extra定位到正确的位置。剩下的问题是如何让main也定位到正确的位置。

一个自然的想法是，给main的容器#bd添加padding:

    #bd {
        padding: 0 230px 0 190px;
    }

效果请看： pe_layout_example2.html.
这样能让main定位到正确的位置，但sub和extra的位置不对了。这是一个思考的关卡。既然sub和extra的位置不对，那就想办法调整到正确的位置。相对定位隆重登场：

    .sub {
        float: left;
        width: 190px;
        margin-left: -100%;
        position: relative;
        left: -190px;
    }
    .extra {
        float: left;
        width: 230px;
        margin-left: -230px;
        position: relative;
        right: -230px;
    }

demo页面： pe_layout_example3.html. 很明显，这就是圣杯布局！

组合这三种基本技术，我们可以继续尝试各种想法。比如伪绝对定位布局（这个布局不难想到，难的是第一个想到），类似的还有逆伪绝对定位布局（先都移动到最左边，然后再margin-right一个个移过来）等等。

在不增加任何额外标签的假设上，我尝试了各种想法，但始终都没找到完美的布局实现（圣杯布局是我觉得所有想法中最接近完美的）。

既然不添加额外标签时，完美布局的实现如此困难，那如果允许添加一个额外标签呢？在淘宝UED内部的探讨中，给main增加了一层包裹：

<div id="main" class="column">
      <div id="main-content">#main</div>
</div>

里层main-content的作用就是将main定位到合适的位置，并方便设置padding等属性。想到此处，就像牛顿被苹果砸傻了一样，原来的main定位问题迎刃而解：

<div id="page">
    <div id="hd"></div>
    <div id="bd">
        <div class="main">
            <div class="main-wrap"></div>
        </div>
        <div class="sub"></div>
        <div class="extra"></div>
    </div>
   <div id="ft"></div>
</div>

CSS仅需增加一行：

.main-wrap {
    margin: 0 230px 0 190px;
}

demo页面： pe_layout_example4.html.

一切如此简单！除了添加了一个额外标签，其它各方面，表现都很完美（试了下IE5.5, 也没任何问题）。目前只用到了浮动和负边距，如果再引入相对定位，还可以实现三栏布局的各种组合：

    .extra {
        float: left;
        width: 230px;
        margin-left: -100%;
        position: relative;
        left: 190px;
    }
    .main-wrap {
        margin-left: 430px;
    }

demo页面： pe_layout_example5.html.

仔细查看example5和example4的源代码，可以发现DOM结构是完全一样的，仅仅CSS稍有不同。这意味着HTML结构和CSS布局在一定程度上解耦了，我们开发HTML代码时，从内容出发即可，无需过多的考虑布局。这正是渐进增强在前端工作流程上的体现。

如果把三栏布局比作一只大鸟，可以把main看成是鸟的身体，sub和extra则是鸟的翅膀。这个布局的实现思路是，先把最重要的身体部分放好，然后再将翅膀移动到适当的地方。因此请容许我给这个布局实现取名为双飞翼布局（Flying Swing Layout）.

就如上图中的鸟有各种姿势一样，利用双飞翼布局，我们也可以实现各种布局。这里有个尝试页面，利用双飞翼，实现了一套栅格化布局系统。

优点

1. 实现了内容与布局的分离，即Eric提到的Any-Order Columns.
2. main部分是自适应宽度的，很容易在定宽布局和流体布局中切换。
3. 任何一栏都可以是最高栏，不会出问题。
4. 需要的hack非常少（就一个针对ie6的清除浮动hack:_zoom: 1;）
5. 在浏览器上的兼容性非常好，IE5.5以上都支持。

不足

1. main需要添加一个额外的包裹层。
2. 等待你的发现与反馈。

补充

双飞翼布局的想法与实现受了圣杯布局和UED内部讨论的PPT的启发。尝试后发现一切如此简单，都有点奇怪为什么网络上一直没有文章来阐述。

前些日子主要精力都放在了阅读ALA上的文章，没怎么注意其它信息。昨天才仔细阅读Eric的Any-Order Columns和Alex的One True Layout, 发现这种思路和想法早就有人尝试过了。比如Eric原文中的例子是定宽的，但稍微修改，就可以演化为双飞翼布局。Alex的One True Layout, 给的例子被墙了，就一直没细看，今天才找代理过去瞄了一眼，一瞄不要紧，原来One True Layout就是双飞翼，不过Alex只用到了浮动和负边距，因此没有提及main - sub - extra这种排列的实现。

此外，中午还有一个非常震惊的发现：Alessandro早做了一个很详细的页面Layout Gala, 列举了40种布局，用的就是双飞翼！

巧合让人有点沮丧，但更让我高兴。因为Alex和Alessandro的工作，证明了这种布局的普适性。因此不用像采用伪绝对定位布局时一样，得担心新技术带来的风险！可以说，双飞翼布局已经是一个成熟的布局，但因为Alex的被墙，以及Alessandro的宣传力度不够，导致这个布局被我重新“发现”了一次。特撰此文，并取名为“双飞翼布局”，希望这个布局能让更多的人知道，并应用于实践中。

<div id="page">
    <div id="hd"></div>
    <div id="bd">
        <div class="main"></div>
        <div class="sub"></div>
        <div class="extra"></div>
    </div>
   <div id="ft"></div>
</div>

main是主要内容，sub是辅助内容，比如导航、相关文章等，extra是额外信息，比如广告等，具体含义根据实际情况来定。书写HTML文档有个非常重要的原则是：重要的内容放前面。这能让文档更富语义，能提高可访问性，对SEO也更友善。

写好上面的代码后，我们来看看如何实现三栏布局。（书写HTML时，尽量以内容为向导，要避免一上来就考虑布局，这体现的是内容与表现的分离，同时也是渐进增强思想在工作流程中的体现。）

Table布局

经典得一塌糊涂的表格布局，在渐进增强面前落花流水——表格布局要求书写HTML代码时，首先考虑布局，而不是内容。不啰嗦，直接枪毙。

Float布局

浮动布局满天飞：

优点是简单，缺点呢？在One True Layout这篇文章中有详细的探讨。或者看我收集的一些Float引发的Bugs.

考虑到IE的庞大市场，目前只好将浮动布局关禁闭了。

绝对定位布局

绝对定位非常简单，非常精准。但面对不可预料的高度时，绝对定位就死翘翘了。可以看看这篇文章，还有一个不错的例子：Flanking Menus.

废话不多说，也关禁闭。

负边距布局

Ryan Brill在2004写了一篇文章：Creating Liquid Layouts with Negative Margins. 文中的“发现”立刻让布局世界迎来了“负来负去”的新时代。对于上面的三栏布局，需要先调整DOM结构：

<div id="hd"></div>
<div id="bd">
    <div class="content">
        <div class="sub"></div>
        <div class="main"></div>
    </div>
    <div class="extra"></div>
</div>
<div id="ft"></div>

最终的CSS实现请看这里。请仔细阅读Ryan的原文，可以发现负边距能解决两栏布局中文档结构的问题（main可以放在sub前面）。但对于三栏布局，Ryan给出的解决方案需要添加额外的包裹层，对DOM结构也依旧存在依赖关系。

这个方法的最大价值是：开启了负边距的神奇大门，让布局的实现思路立刻活跃了起来。

圣杯布局

2006年，Matthew Levine开始寻找布局圣杯：In Search of the Holy Grail. 这是一篇让人赞叹振奋的文章。Matthew灵活运用容器的内边距、浮动元素的负边距和相对定位，接近完美的实现了三栏布局。DOM结构也很好，无需额外标签。但是，我们来看看多达27页的评论吧。圣杯布局最令人头疼的是：在IE6下，左栏经常会神奇消失！！！（比如将IE6的窗口高度拖小点）评论中还反馈在IE7下也存在不少问题（我测试后，发现在IE7正式版下没问题，评论中的IE7可能是beta版）。另外在Chrome下表现也有点诡异，需要小小hack. 还有那繁琐的padding, margin, left, right计算，时刻需要一颗清晰的大脑，喝点小酒就彻底晕了……

这里还有篇文章专门分析了圣杯布局在IE6下的Bug: Jump on hover in Ala’s Holy Grail layout.（万恶的IE6啊，浪费了我们多少宝贵的时间）

2008年11月4日补充：这里有一个改进版的圣杯布局，解决了所有问题，缺点是包裹层太多，唉。

总之：这是一个很美妙的布局，但在IE6尚未退出历史舞台的当今，圣杯布局可能并不是我们真正要找的圣杯。

伪绝对定位布局

聪明的同行们对完美布局的追求孜孜不倦。2008年我们迎来了奥运。Eric Sol 给奥运的献礼是一个聪明的布局尝试：Faux Absolute Positioning.

这个布局思路很简单：先相对定位到最右边，再用margin-left移过来。关于这个布局，曾经引发了淘宝UED内部的热烈讨论。若干月后，我和明城在不同的项目中采用了这一方法，结果发现在ie下，某些页面会闪屏（页面加载时能看见左移）。当时项目紧，没细究，上周想重现却怎么也重现不了（明城说页面非常复杂的时候会闪屏，但具体原因没找出来）。今天看原文的评论，有人指出在IE6下，设置背景图会导致这个布局彻底完蛋。

仔细想来，这个布局最让人担心的是：为什么一开始要将所有item都left: 100%? 这个太邪恶了，让人不放心。

“借尸还魂”的Table布局

乍一看，这个布局很雷人：基于display:table的CSS布局。作者作了解释：在css里使用table-cell之类的声明，仅是声明渲染方式，并不影响HTML文档中的语义。从这个角度讲，这种布局方式的确不错，而且很容易就可以做到等高，也不用考虑清除浮动等扰人的问题。

但是，又是IE成了绊脚石。在IE中，这个布局需要IE8才支持。不过，即便所有浏览器都支持了，我为什么老觉得有点“借尸还魂”的感觉？

更多

布局世界精彩纷呈，下面这些文章也非常有影响力：

• Eric的Any-Order Columns, 对于固定宽度的三栏布局，Eric的方案非常优秀。
• 大名鼎鼎的One True Layout, 里面很多总结性质的研究，非常值得一读。

小结

可以看出，有不少布局（比如圣杯布局、伪绝对定位布局、One True Layout等）都符合渐进增强的工作流程。圣杯布局和One True Layout里，都把negative margin发挥到了极致（让我对浮动元素的负边距有了彻底的了解）。伪绝对定位布局则让人很不放心left: 100%，用来解决原文中的问题感觉不错，但如果用来作为整个页面的布局，则有点邪恶。

布局中究竟有没有圣杯呢？下一篇中将给出我的尝试。

从1994年开始，Web开发社区就敲响了优雅降级（Graceful Degradation）的鼓声。这个概念来自工程世界，其核心理念是给最新最强大的浏览器全套餐式的体验，而给那些不幸还在使用Netscape 4的可怜人们只留些残羹冷炙般的基本功能。毫无疑问，这发挥了作用。但是它并不很符合Tim Berners-Lee（译注：万维网之父）关于普遍可访问性网络（Universally Accessible Web）的原始愿景。

大约10年后，一些聪明的家伙开始质疑优雅降级，发现它在很多层面上有不足之处。他们将精力集中在内容可用性（Content Availability）、总体可访问性（Overall Accessibility）和移动设备浏览器的能力上，寻找到了一条Web开发的新途径——此方法将内容作为关注焦点，而不只是对旧设备的支持嘴上说说却没有实际行动。

在2003年的SXSW会议（译注：一个关于电影、音乐和交互的会议）中，Steve Champeon和Nick Finck做了名为 “面向未来的全方位Web设计” 的演讲。这样，他们揭示了这种Web开发新方法的蓝图。Steve还给它取了个名称：渐进增强（Progressive Enhancement）。

这里有个（微妙的）差别

如果你挠着头想弄清楚优雅降级和渐进增强的区别，我告诉你，这是视角问题。优雅降级和渐进增强都考虑网站在各种设备的各种浏览器上如何良好运转。两者区别的关键在于它们各自关注的焦点，以及这种关注对工作流程的影响。

优雅降级的视角

优雅降级关注于在最先进/最全能的浏览器上构建网站。在被认为“老的”或能力不足的浏览器中的测试，经常要等到开发周期的最后一个环节才进行，并且通常限制在主流浏览器（如IE、Mozzila等）的前一个发布版本中。

在这种模式下，老的浏览器只可能提供差强人意（poor, but passable）的体验。或许会做些小补丁来适应某个特定浏览器，但这些浏览器毕竟不是关注的焦点，除了修正重大的错误，也不会再费多大的神了。

渐进增强的视角

渐进增强关注于内容。请注意区别：我甚至都没提及浏览器。

内容是我们最初创建网站的原因。有些网站传播内容，有些收集内容，有些请求内容，有些操作内容，有些网站以上所有功能都有，然而它们都需要内容。这就是渐进增加成为一种更适合的模式的关键所在。这也是Yahoo!迅速采纳这种模式并用它创建了分级浏览器支持（Graded Browser Support）策略的原因。

它是怎样运作的

进入渐进增强的思维方法很简单：只要从内容开始往外想。内容形成坚实的基石，在此之上才能添加样式和交互。如果你爱吃糖果，可以将它想像成一颗M&M花生巧克力：

（图示：渐进增强的巧克力层）

从内容花生开始，将其标记为富含语义的(X)HTML. 接着给内容裹上一层富含奶油的CSS. 最后，添加JavaScript作为糖果硬壳，这就做成了一颗可口无比的美味（并使得它不会在你手里融化）。

如果非常熟悉Web标准化运动的口号——分离、分离、分离——这个类比就相当清楚了。基于Web标准的开发经常被比作夹心蛋糕（或者，可以更富想像力地比作为松糕（译注：一种多层蛋糕，可以夹水果、奶油、沙司等））。

我更倾向拿M&M花生巧克力来类比，因为它的外层把内容完全包裹住了，这和我们的样式与脚本将内容包裹起来几乎是一样的。

如果你允许我的食物类比论再多讲一点（希望不会让你感觉饥饿），我将解释为什么这种方式更好以及在这种模式下各层之间是如何交互的。

花生仁

有些人喜欢花生。实际上，有人喜欢花生胜过M&M花生巧克力。类似地，有些家伙（以及像搜索引擎爬虫这类东西）只想要内容。

还有些人无福消受花生上的巧克力和糖果层（例如糖尿病患者）。和他们类似，移动设备或老浏览器用户可能无法看到漂亮的设计，或者与流畅的AJAX驱动的界面交互。

确保标记能够将所包裹的内容的细节最大限度地传达出来，这对于给这些用户提供基本体验至关重要。

巧克力外衣

接下来，可以将内容小心地浸入芳香美味的CSS暖浴中了。不过在跳进糖果硬壳之前，还有些额外的考虑。

有的人爱吃巧克力裹着的花生。这些人就像中级用户，他们的浏览器有比较好的CSS支持，但可能没有很好的JavaScript支持。或者，可能在他们工作的公司里，IT安全人员对JavaScript极其病态性地恐惧。对他们来说，JavaScript就可能完全被禁用了。

无论是倾向于爱吃巧克力花生（译注：一种直接用巧克力覆盖的花生，没有外层硬壳，类似于有内容和CSS但没有JavaScript支持的网站）还是被限制只能吃巧克力花生，这些人都应该得到满足。这里有几种渐进增强的方式可以将样式应用于内容，这将是本系列第二篇文章的话题。

糖果硬壳

最后，可以将JavaScript添加到内容和样式的混合体中了。JavaScript提供了富交互的可能性，同时具有操作内容层和展现层并与其交互的能力，这实际上使得JavaScript成为了把网站带入“体验”高度的一味配料。

我不确定糖果硬壳到底是怎样添加到M&M花生巧克力上的（我猜是另一种什么浸蘸过程吧），但是，在脑中想着渐进增强的话，在网站上加入基于JavaScript的功能和交互就轻而易举了。另外，就如M&M花生巧克力有各种各样颜色一样，依据所运行的浏览器和设备的能力，JavaScript的体验也可以各不相同。

正如你可能知道的那样，这种类型的开发叫做无侵入式（Unobtrusive）JavaScript. 我将在本系列的第三篇和最后一篇文章中讲述这些技巧和实践。

都放在一起

一旦理解了渐进增强的理念并开始在实践中使用，那么用渐进增强进行开发就非常简单了。也许比做糖果还简单。本系列接下来的两篇文章将帮助你使用CSS和JavaScript来磨练你的渐进增强技巧，并展示怎样把哲学转换成代码。

~~~~~~

译注：

1. Graceful Degradation有译为预留退路、平稳退化的，但我觉得这两个翻译没有表达原意，不如直接翻译成优雅降级的好。
2. Unobtrusive有译为不唐突的、分离的、低调的，在Web开发领域，我觉得翻译成“无侵入的”最能表达原意。

2008年10月08日 射雕&安吉 译于杭州
2008年10月09日 审校
2008年10月14日 根据taine的建议，去掉了译文中许多“你”、“你的”等无意义词