google这篇文章关注的是资源被下载到客户端以后，在浏览器加载、解释、渲染HTML、CSS和JavaScript阶段的性能优化，提出了5个要点：

1. 使用高效率的CSS选择器
2. 避免CSS expressions
3. 将样式表放在页面顶部
4. 指定图像尺寸
5. 尽早指定文档的字符编码

前四点大布同学已经翻译过了，没拜读过的同学可以点击上面的链接到涛哥的博客学习，第五点的翻译如下：

概述

为HTML文档尽早指定字符编码，可以让浏览器立刻开始执行脚本。

细节

HTML文档是作为带有字符编码信息的字节流序列在互联网中传送的。字符编码信息可以在随文档发送的HTTP响应头信息中指定，也可以在文档的HTML标签中指定。浏览器根据字符编码信息将字节流转换为显示在浏览器上的字符。如果不知道如何构造一个页面的字符，浏览器自然也不能正确地渲染页面。绝大部分浏览器在开始执行任何JavaScript代码或者绘制页面之前都要缓冲一定数量的字节流，缓冲的同时它们也要查找相关的字符编码设定（一个值得注意的例外是IE6/7/8）。

不同浏览器需要缓冲的字节流数量不同，另外如果找不到编码设定，各浏览器默认的编码也不同。但是不管哪一种浏览器，如果在已经缓冲了足够的字节流、开始渲染页面之后才发现指定的编码设定与其默认值不同，都会导致重新解析文档并重绘页面。如果编码的变化影响到了外部资源（例如css\js\media），浏览器甚至会重新对资源进行请求。

为了避免这些延迟，对任何超过1k（精确地说是1024字节，这是我们测试过的所有浏览器的最大缓冲限制）的HTML文档，要尽早指定字符编码。

建议

通过HTTP头信息或meta标签指定编码

为HTML文档指定编码设定有几种方式：

服务器端：通过web服务器的配置来指定编码参数，为所有text/html类型的文档指定带有正确编码信息的Content-Type头信息。例如 Content-Type: text/html;charset=UTF-8

客户端：在HTML代码中包含http-equiv="content-type"的meta标签，并指定字符编码。例如 。

如果可能的话，为你的web服务器做指定字符编码的HTTP头信息配置。某些浏览器（例如Firefox）在执行JavaScript之前会用（比其它浏览器）更短的延迟缓冲来检查头信息中是否指定字符编码。这意味着它们可以跳过对HTML标签的检查，缩短缓冲的字节数和延迟时间。

把meta标签放在head区域的最前面

如果你不能对web服务器配置进行修改，又需要通过meta标签指定编码，要确保你用于指定编码的meta标签是文档中head标签的第一个子元素。浏览器会在文档的前1024字节中寻找字符编码参数，因此为了避免性能损耗，编码参数在文档头部越早出现越好（译注：在IE6以下的版本中，特定情况下，如果该meta标签不是head的第一个子元素，则会被忽略。具体触发情况尚未进行仔细测试，初步估计是与web服务器配置的默认编码或浏览器默认编码有关）。

始终指定文档类型

在浏览器开始检查字符编码设定前，它们必须先检测将被处理的文档是什么类型。如果没有在头信息或meta标签中指定文档类型（content-type），浏览器就会通过很复杂的算法去“嗅探”文档的类型。这个过程会造成额外的延迟，而且还会带来安全漏洞。

务必指定正确的字符编码

你在HTTP头信息或meta标签中指定的字符编码设置一定要和编辑HTML文档时的实际字符编码一致，这非常重要。另外，如果同时通过HTTP头信息和Meta标签两种方式指定了字符编码，它们一定要保持一致。否则浏览器发现两者相互矛盾，会造成页面渲染错误或者为了重绘页面而造成额外的延迟。有关这一点，你可以阅读HTML 4.01规范（英文）中的5.2节：字符编码（英文）。

扩展阅读

如果需要进一步了解content-type以及字符编码设定存在/缺少的不同情况下浏览器行为的细节，可以参阅以下资料（英文）：

• Page Speed wiki
• Browser Performance Issues with Charsets
• Performance Implications of "charset"

相关日志

• 2010-06-09 -- 最近的书单
• 2009-06-22 -- Whatever:hover – 无需javascript让IE支持丰富伪类
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-22 -- HTML验证的价值探讨【译】
• 2010-10-20 -- clearfix改良及overflow:hidden详解【译】
• 2009-12-21 -- 前台开发从头说起：理解css盒模型
• 2009-12-16 -- 前台开发从头说起：谈谈CSS选择符
• 2009-12-15 -- 前台开发从头说起：关于web标准化
• 2009-04-13 -- 简单、通用的JQuery Tab实现

译文：http://ofcss.com/?p=1078

作者：Thierry Koblentz （雅虎前端工程师）

用css边框实现小三角的技巧现在已经被越来越多的网站所采用，减少图片、减少HTTP请求的低碳设计越来越受欢迎。这次，来自雅虎的前端工程师又给我们带来了一组新的CSS边框设计技巧，原文列出了三种（双色背景导航条、水平排列元素间的点线分隔符、带左右箭头的垂直导航条），实际上除了这三种外，其范例页中还给出了额外的两种（水平分页导航条、垂直分组导航条）。以下是译文：

双色背景

原文并未直接给出IE6/7的处理说明，但是在范例页的样式中包含了IE6/7的Hack，这里我把它们摘出来放在下方，你也可以狠狠点击原文范例页面自行查看。

#menuBar-A {
    display: inline-block;
    text-align: center;
    border: 1px solid #cecece;
}
.child {
    display: inline-block;
    line-height: 0;
    height: 0;
    border-top: 1em solid #ffc;
    border-bottom: 1em solid #fdcf46;
    padding: 0 .6em;
    vertical-align: bottom;
}

<ul id="menuBar-A">
    <li><a href="#">About Us</a></li>
    <li class="selected"><a href="#">Contact Us</a></li>
    <li><a href="#">Services</a></li>
    <li><a href="#">Products</a></li>
</ul>

/*
 * IE6/7 Hacks
 * 用display:inline + zoom来模拟display:inline-block;
 * 基于IE对列表元素的样式渲染方式，不能对其使用垂直边框，因此用它的背景色代替 */
#menuBar-A {
    #display:inline;
    #zoom:1;
    #border:0;
    #padding:1px 0 1px 1px;
    #background:#BD9E43;
}
#menuBar-A li {
    #background:#ffc;
    #border:0;
    #margin-right:1px;
    #border-bottom:1em solid #fdcf46;
}
#menuBar-A a {
    #line-height:1;
    #border:0;
    #position:relative;
    #top:-.65em;
    _top:.3em;
}
#menuBar-A li:hover a {
    #color:#fff;
}
#menuBar-A a:hover,
#menuBar-A a:active {
    _color:#333;
}
#menuBar-A .selected,
#menuBar-A li:hover {
    #background:#c789d9;
    #border-bottom-color:#83358B;
}
#menuBar-A .selected a:hover, {
    #color:#fff;
}

列表元素之间的点/线分隔符

这个例子只需要做少量的IE Hack就可以完美实现跨浏览器兼容。

ul.one, ul.two {
    margin-left: 0;
    display: inline-block;
    #display:inline;
    #zoom:1;
    height:12px;
    line-height:12px;
    padding:0;
}

li {
    float: left;
    display: inline;
    height: 2px;
    line-height: 2px;
    position: relative;
    top: .3em;
}
li.selected {
    font-weight:bold;
}
ul.two {
    border-left: 1px solid #333;
}

ul.one li {
    border-left: 2px solid #333;
}

ul.two li {
    border-right: 2px solid #333;
}

ul.one li.first-child, ul.two li.last-child {
    border: 0;
}

a {
    color: #000;
    padding: .4em .9em;
    #position:relative;
}

<div id="menuBar-B">
    <ul class="one">
        <li class="first-child"><a href="#">About Us</a></li>
        <li class="selected"><a href="#">Contact Us</a></li>
    </ul>
    <ul class="two">
        <li class="last-child"><a href="#">Services</a></li>
        <li><a href="#">Products</a></li>
    </ul>
</div>

左右三角图标

原文并未直接给出IE6/7的处理说明，但是在范例页的样式中包含了IE6/7的Hack，这里我把它们摘出来放在下方，你也可以狠狠点击原文范例页面自行查看。

#box {
    line-height: 0;
    height: 0;
    border: .4em solid transparent;
    border-left-color: #333;
    border-right-color: #333;
    padding: 0 .3em;
    display: inline-block;
}

<ul id="menuBar-C">
    <li><a href="#">About Us</a></li>
    <li class="selected"><a href="#">Contact Us</a></li>
    <li><a href="#">Services</a></li>
    <li><a href="#">Products</a></li>
</ul>

/* IE6/7 Hacks */
#menuBar-C {
    #display:inline;
    #zoom:1;
    #width:10em;
}
#menuBar-C li {
    #padding:0;
    #margin:.4em;
    #list-style-type:none;
    #height:0;
    #border-top:.4em solid #fff;
    #border-bottom:.4em solid #fff;
    #border-left:.4em solid #2F2876;
    #border-right:.4em solid #2F2876;
    _position:relative;
}
#menuBar-C a {
    #border:0;
    #height:auto;
    #line-height:1;
    #top:-.4em;
    #position:relative;
    _position:absolute;
    #left:-.4em;
}
#menuBar-C li:hover {
    #border-left:.4em solid #f60;
}

IE6与透明边框

IE6不支持用于边框颜色的“transparent”关键字。如果在IE6下指定边框颜色为透明（transparent），IE6将会绘制成黑色边框。

解决办法是使用 chroma filter，它可以让对象内容中的指定颜色显示为透明色（译者注：针对IE6，还有其它的解决办法，参见IE 6 的边框不透明 bug）。例如，创建一个向右箭头，可以这样做：

#Box {
    height: 0;
    width: 0;
    border: 10px solid transparent;
    font-size: 0;
    _border-color: pink;
    _filter: chroma(color="pink");
    border-left-color: #333;
}

规则中的font-size的定义是为了解决IE6下自动撑开元素高度的问题。

译注：

1. 原文给出的css样式和html结构不对应，在译文中已做修正。
2. 原文作者对IE6/7的注释采用两种方式：*号引导属性名、以及规则最后一个选择符带逗号，在译文中我统一使用了#号引导属性名的方式。为了部分原来不清楚这些hacks方式的读者，下面再把作为本文背景知识的IE6/7、IE6 Hacks符号简单说明一下：
   • IE6/7 均支持以“*”号、“#”号引导的属性名称，其它浏览器不支持。因此，针对IE6/7的Hack可以写为：
     #zoom:1或*zoom:1
   • IE6/7 均支持最后一个选择符后面跟逗号的规则，其它浏览器不支持。因此，针对IE6/7的Hack也可以写为：
     .selector, {zoom:1}
   • IE6 支持以下划线引导的属性名，其它浏览器不支持。因此，针对IE6的Hack可以写为：
     _width:600px;

以上只是用边框实现“无图化”设计的众多技巧中的一小部分，实际上我们还可以做得更多。如果有兴趣，你可以继续阅读：

《自适应圆角》

《CSS Border三角、圆角图形生成技巧》

相关日志

• 2011-03-20 -- 容易被误解的overflow:hidden
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-12 -- 自适应的多列图文混排改进
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-20 -- clearfix改良及overflow:hidden详解【译】
• 2009-06-22 -- Whatever:hover – 无需javascript让IE支持丰富伪类
• 2011-05-26 -- 深入解析CSS样式层叠权重值
• 2011-03-07 -- IE8/9兼容性设置
• 2011-03-04 -- 在非IE浏览器中模拟zoom创建块级上下文【译】
• 2010-10-30 -- webkit中BFC元素临近浮动元素时的边距bug

译文：http://ofcss.com/?p=1028

作者：Thierry Koblentz

尽管这种情况通常被称为"浮动下坠"或者"浮动下沉",但实际上下坠或下沉的列并不一定是浮动的……只要它比预留给它的空间更宽就有可能出现下沉。请记住这是一种特定情况下才会发生的在跨浏览器时很常见的行为——网页的某一栏太宽了，于是它下沉了。

IE 6的问题之所以突出，是因为它对 width 这个属性的支持不完整（height 也好不到哪里去）。因此，IE 6会让容器扩展以适应内容。而为这个容器设计的宽度却没法随之变宽，于是IE 6对容器宽度的自动扩展就造成了它的下沉。

通常情况下，罪魁祸首是那些无法包围的元素（比如图片、url等），但是文字样式（例如 IE 和 斜体）也有可能造成这种情况。

例如，要让YUIBlog的右栏在IE 6中下沉，我只需要让右栏中的某个图片的宽度大于210px。这张图将会强迫IE 6增加右栏的宽度，这样右栏就无法再保持在左栏旁边了。

常见修复方法：

• word-wrap: break-word;//强制文字截断（译注：主要针对非双字节语言，把单词强制截断）。
• wbr with wbr:after {content:"\00200B"}; //针对 Opera，wbr属性代表行截断的机会。在长文字中添加wbr以便在必要时允许浏览器换行。
• overflow-x:hidden;//隐藏溢出容器的所有内容。

要注意的是前两种方式只适用于文字，不能放置图片撑开容器。

已知会导致修复失败的情况

几周前，我遇到要为yahoo!财经的页面修复“浮动下沉”的bug。在现代浏览器中，一行长文字超出了容器显示在容器右侧外部（查看截图），但是在IE 6下，同样的文字造成了右栏下沉到主栏下方（查看截图）。麻烦的是，这部分内容是由外部提供，因此没办法对HTML代码进行修改。

由于这行文字是一组由逗号分隔的标签列表，因此之前提到的几种修复方法都不能满足需要。在这行文字内部任意位置强行截断当然比隐藏溢出部分要好，但这也不是可行的解决方案。

让IE 6正常显示

要让IE 6像其它现代浏览器一样显示这行文字，方法是给文字的容器的右边距设置一个负值（同时还要设置相对定义position:relative）。

效果演示

没有修正时

fix 修正以后

代码示例：

.fixMe {
  margin-right:-100px;
  position:relative;
}

负边距可以设置为任意大的值，只要大于实际所需宽度和指定宽度的差值即可。这就是我所说的放置浮动下沉的方法。设置相对定位（position:relative）的目的是让IE能够显示超出了父元素边缘的内容。

Things to consider 补充说明

这个hack能保证每一栏都呆在应该在的位置上，但是无法阻止溢出内容的容器变宽。因此你不能在该容器上应用背景或者边框样式，否则这些样式都会显示到父元素外部。下面有个截图，演示了在IE 6下使用这个方法同时设置边框和背景的效果：

相关日志

• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-30 -- webkit中BFC元素临近浮动元素时的边距bug
• 2010-10-20 -- clearfix改良及overflow:hidden详解【译】
• 2009-06-22 -- Whatever:hover – 无需javascript让IE支持丰富伪类
• 2011-05-26 -- 深入解析CSS样式层叠权重值
• 2011-03-20 -- 容易被误解的overflow:hidden
• 2011-03-12 -- 自适应的多列图文混排改进
• 2011-03-07 -- IE8/9兼容性设置
• 2011-03-04 -- 在非IE浏览器中模拟zoom创建块级上下文【译】

原文:http://briancray.com/?p=1584

【作者简介】Brian Cray 居住在俄亥俄州的哥伦布市，是位于圣弗朗西斯科的Topsy公司的一名前端工程师。

本文主要介绍如何使用谷歌分析的高级事件跟踪能力，深入了解用户如何浏览你的网站、如何与你的网页进行交互。

=========== 以下为译文正文===============

Google分析服务的设置，对于访问者浏览行为和偏好的信息，仅记录和分析了他们的来路和被访问的页面。但这些信息就足够告诉你访问者在网页中的用户行为了吗？不够！这些只是帮助我们分析用户行为的最基础的信息。

我想请你根据你目前的Google分析的设定回答以下问题：

• 你的用户是通过主菜单还是通过其它方式来查找你站内的内容？
• 你的用户在查看较长的页面时向下滚动和点击底部的链接吗？
• 你的用户是点击文章的标题还是点击“查看详情”链接？
• 你的用户真的会使用下拉菜单里的项目吗？还是根本没注意到下拉菜单？
• 你的用户接受你建议的的相关文章吗？

现在让我来帮助你回答其中的一部分问题

借助Google分析服务的事件追踪，可以跟踪在你网页上发生的任意事件——包括用户的行为。

在开始之前，有两个重要步骤需要先做：

• 把你的Google分析的跟踪代码改为异步跟踪的代码。
• 把jQuery代码移到页面的<head>标签里（我知道，这是违背优化标准的，但是如果你使用良好的缓存技术的话，后面的数据回报是绝对值得你这样做的）。

代码

把以下代码添加到你的网页的<head>标签中或者你当前的jQuery代码中（只有该代码在<head>标签中时才可以）。

$(function () {
    $('a').click(function () {
    // 通知分析服务存储事件
        try {
            _gaq.push(['_trackEvent', thisel.parents('[id!=""]:first').get(0).id, 'clicked', (thisel.text() || thisel.children('img:first').attr('alt'))]);
        }
        catch (err) { }

        // pause to allow google script to run
        var date = new Date();
        var curDate = null;
        do {
            curDate = new Date();
        } while (curDate - date < 300);
    });
});

添加代码后对事件按分类查看的截图

在添加以上的代码后，可以看到网站的那些部分被点击得最多（基于元素的id属性或者父元素）。

添加代码后对事件按标签查看的截图

在添加以上的代码后，从左边的下拉菜单中选择某一个事件分类，可以看到被点击过的链接的标题，例如下图中能够看到的菜单项中的链接文字。

通过事件追踪获得有关用户行为分析的更多信息

前面所讲的，只是对这个强大技术的一点点入门介绍。借助用户行为分析方面的知识和恰当的jQuery技术，你还能以更丰富、更深入的方式使用它。例如：

• 追踪用户的表单行为和鼠标行为。
• 追踪用户的操作和操作之间的时间。
• 改变设计，然后观察这些改变如何影响用户的行为（类似于A/B测试）。

Fabian Pimminge 已经在 MooTools 上重写了这些代码，如果你使用的是 MoonTools 框架，可以参考这篇文章。

相关日志

• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-22 -- HTML验证的价值探讨【译】
• 2010-10-20 -- clearfix改良及overflow:hidden详解【译】
• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-07-01 -- ASP.NET MVC 最佳实践（二）
• 2009-06-28 -- ASP.NET MVC 最佳实践（一）
• 2009-06-22 -- Whatever:hover – 无需javascript让IE支持丰富伪类

原文：http://www.nczonline.net/blog/2010/08/17/the-value-of-html-validation/

这篇文章我已经酝酿了很久，期间还拜读了 Chris Heilmann 关于 Remy Sharp’s site 的这篇大作。我和Chris曾就这个话题多次交换意见，最终我们彼此的观点都有所改变，接受了一些过去无法接受的意见。我曾经在公开的、私下的各种场合直言不讳地表示过，目前的HTML验证状况对我来说纯粹是浮云。要了解我的看法，你需要先明白HTML验证到底是什么。

什么是HTML验证

HTML验证是对你的网页代码执行一系列验证任务，主要包括：

1. 代码语法验证 - 检查语法错误。从技术上说，尽管 <foo> 不是HTML规范中的一个标签，<foo bar="baz"> 在语法上也是正确的，所以语法验证唯一的作用就是确保编写出合法的HTML代码。
2. 标签嵌套验证 - 检查标签是否正确地按照打开的先后顺序关闭。比如一个<div>标签没有被正确关闭的话，在这项检查中就会报错。
3. DTD定义验证 - 检查你的代码是否遵循了指定的DTD的定义。这项验证检查的内容包括标签名称、属性名称、以及标签包含关系（某个标签是否允许被嵌套在另一个内部）。
4. 异常实体验证* - 检查是否存在DTD规范中不曾提及的任何东西。通常自定义标签和自定义属性就会在这一项验证中报错。 （*译者注：关于原文中的Outlier Validation，指的是对不属于DTD定义范围内的实体的验证。在数学上，把这种游离于基准之外的值成为离群值，因而在数学上有Outlier Validation - 离群验证的概念。但是在HTML中，对于DTD中的元素、属性，均是实体，这项验证要做的是找出不在定义范围内的异常实体，因此暂译为“异常实体验证”，若您有更好的翻译方案，欢迎探讨。）

请记住：以上这四项验证任务只是为了便于理解而进行的逻辑划分，而不一定是验证器真正的实现方式。如果在某个验证任务上失败了，就说明HTML代码在该项对应的方面存在问题，是不符合规范的。

关于HTML验证的争论

HTML验证的支持者的主要观点是：HTML验证能够保证网页在不同浏览器下的互用性。不同核心的浏览器拥有不同的语法分析器以及HTML验证的具体实现。只有同时满足所有浏览器的要求，你的代码才能始终正常工作。由于每个浏览器在其语法分析器中各自以不同方式来实现纠错功能，因此对于不规范的代码，我们无法预计浏览器会如何呈现它。

而HTML验证的反对者则认为：HTML验证过于严格，而且没有考虑到浏览器的真实工作情况。HTML中的某些情况虽然从技术角度看可能是不合规范的，但是所有的浏览器都能按照相同的方式处理它们（注：并不总是相同的方式）。如果我自己能对自己编写的不规范代码负责，那我就不需要担心什么HTML验证——我真正关注的只是让这个网页正确呈现。

我的观点

我很少会就某个争论的问题公开表态，这恰好是其中之一，希望你喜欢。基于“HTML验证过份严格，不符合实际工作场景”的原因，我一直都属于反对HTML验证的阵营。有一些被浏览器广泛支持的东西（<head>里面的<noscript>，</html>之后的<script>）居然也不符合规范，而为了得到正确的用户体验，它们有时候却是必不可少的。

总的来说，HTML验证给我造成的麻烦主要集中在第四项（异常实体验证）。我喜欢在HTML中用自定义属性为特定元素提供额外元数据，而且坚持这种做法。对我来说，要为某个元素提供关联数据时，只需给它增加一个相应的属性。某些人某种时候使用一个合法的属性的目的纯粹是为了让代码能够通过验证，哪怕这个属性根本不是设计来在这种情况下用的。我绝不认同这种做法。

浏览器有个恶心的小秘密，那就是它们根本不会按照DTD文档定义去做HTML验证。你加在网页顶部的文档类型（doctype）只是让语法分析器切换到某种指定的工作模式，但是没有任何一种工作模式会去下载该文档类型的DTD然后验证代码是否符合DTD规定。这是什么意思呢？这就是说，浏览器只是用一个简单的语法分析器来处理HTML，而这个简单的语法分析器只包含一些关于自关闭标签、块元素对行内元素的指定异常而已（我相信其它情况也是如此）。

就自定义属性而言，所有的浏览器都会把它们当作正确的属性一样处理，并因此使得JavaScript可以通过DOM对它们进行操作。浏览器不仅在分析自定义属性的时候不报错，而且在处理阶段也会像把它们当作正常的属性来处理！那么，即使这些自定义属性不能通过HTML验证，我们又何须在意呢？我还会继续使用自定义属性，而且我们都看到HTML5已经正式把自定义属性作为数据集了，哥很欣慰。

还有个很好的例子：ARIA是一项却极其重要的技术，但是按照验证器的检查结果，ARIA却是不规范的HTML。ARIA 技术是在HTML4的基础上添加自定义属性实现的。这些元素为HTML元素提供额外的语义，浏览器能够把这些语义传递给专为不健全人士设计的辅助设备，帮助他们更方便地使用web。当今所有的主流浏览器都支持 ARIA 标签，然而如果你在网页里添加这些属性，你的网页就不能通过HTML验证了。

此外还有被当作错误修正的一部分而被抛弃的自定义标签。我对此没有很强烈的体会，但是个人而言，我觉得如果语义正确的话，在页面中使用自定义标签应该是可以的，只是目前未知我还没有遇到这方面的很好的案例。

再明确一下我的立场：我坚决认同HTML验证的第一项（译注：代码语法验证）和第二项（译注：标签嵌套验证）是很基础、很重要的，应该进行验证并确保通过。第三项（译注：DTD定义验证）也还算重要但是不如前两项。第四项（译注：异常实体验证）的重要性我是不认可的，因为它涉及到自定义属性的使用。异常实体验证顶多只能标记为警告级别，以提醒我们做二次检查看是不是拼错了属性名称。把自定义标签标记为错误或许是个好主意，但是会有一些不利影响——因为它关系到一些其它内容的嵌入标签，例如SVG和MathML(本质上，这些每一种情况都需要成为解析器里的一种特殊异常)。

为了验证而验证？

我要以最强烈的方式表达这个观点：为了验证而验证纯属有病！规范的HTML意味着通过了全部四项检查，但是还有很多东西是仅靠“规范的HTML”不能保证的：

• 规范的HTML不能保证可用性
• 规范的HTML不能保证良好的用户体验
• 规范的HTML不能保证网站功能正常运作
• 规范的HTML不能保证正确的布局

拥有规范的HTML代码或许可以看作一枚荣誉勋章，带给你病态的满足感。但是它本身不是一种成功，更不是衡量成功与否的标准。你的（通过验证的）代码实际运行起来未必比我的（未通过验证的）代码效果更好。

HTML5 验证

HTML5验证修正了我和其他人在HTML4验证中遇到的一些问题。它明确地支持ARIA属性，你也可以添加自定义属性，只要它们以“data-”开头即可。这些情况在HTML5中都被认为是合乎规范的。与HTML4验证相比，这令我满意。要声明的一点是，HTML5验证器中仍有一些我不赞成的部分。尽管如此，我还是认为HTML5验证器比HTML4验证器更好地反映了实际的工作用例。

学术问题，文明探讨

我确实认为HTML验证服务中的某些部分是非常有用的，但是我不想被它挟持，因为我要用自定义属性。我在日常工作中很自豪地使用着ARIA规则，并且根本不在乎它们会让HTML4验证器不爽。再说一次：验证器总共有四个任务，只有一个让我不爽，而HTML5验证器注意到了我的需求。

我知道我谈论的是一个热点问题，它将会引出更多的帖子和博文。我已经在评论表单前做了免责声明，但还是要提醒大家在今后的讨论中保持文明，提供建设性的意见。我还知道双方接下来肯定会有非常强烈的争论并且每个人都会有各自的重点（作者注：我没有刻意押韵；译者注：我也没有刻意押韵）。在评论中出现良性的、强烈的辩论非常好，但让我们都约束一下自己的火爆脾气。这是一个知识性的辩论，不是一个感性的辩论。我要声明，我会比以往更加严格地审核评论 —— 所以希望大家都规矩点。

免责声明：本文所表达的任何观点和看法都仅代表 Nicholas C. Zakas 个人，与 Yahoo！，Wrox 出版社，O'Reilly 出版社 无关，与其它任何人无关。我仅代表我自己，不代表他们。

你可以在我的站点留言，或者从你自己的站点发送 trackback。

相关日志

• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2010-10-20 -- clearfix改良及overflow:hidden详解【译】
• 2009-06-22 -- Whatever:hover – 无需javascript让IE支持丰富伪类
• 2011-03-12 -- 自适应的多列图文混排改进
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-30 -- webkit中BFC元素临近浮动元素时的边距bug
• 2010-10-25 -- 借助jQuery和Google分析服务的事件追踪深入了解用户行为【译】
• 2010-10-24 -- 在WebKit中并行加载外部脚本【译】
• 2010-06-09 -- 最近的书单

clearfix 和 overflow:hidden 可算得上是不增加额外标签清除浮动的两个最流行的技术了。

这篇短文介绍了如何改进clearfix进行增强，同时对overflow:hidden进行了深入的解释。

clearfix

曾经在网上流行的一种clearfix的方法：

.clearfix:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
    }
* html .clearfix { zoom: 1; } /* IE6 */
*:first-child+html .clearfix { zoom: 1; } /* IE7 */

在作者的另一篇文章 everything you know about clearfix is wrong 中，他介绍了这种方法在跨浏览器兼容时会造成的问题，并建议仅对不邻近浮动元素的元素应用clearfix（例如弹出窗口），尽管这样做我们还需要处理由clearfix造成的边距折叠bug（译者注：指clearfix的盒子内部元素的垂直边距被扩展到盒子之外）。有一个demo页面解释了这个问题。

该页面中最开始的两个盒模型的边距叠加行为（底边距保留在盒子内部，顶边距则到了盒子外部）说明：生成的内容将盒子内部元素的边距保留保留在了盒子内部，而在其它浏览器下边距将被扩展到盒子边缘之外。

因此，为了创建跨浏览器兼容的同样的盒模型布局，我们可以把原来的清除浮动的方法改良一下，采用伪类:before 和 :after：

.clearfix:before,
.clearfix:after {
  content: ".";
  display: block;
  height: 0;
  visibility: hidden;
}
.clearfix:after {clear: both;}
.clearfix {zoom: 1;} /* IE < 8 */

如此一来可以使顶边距和底边距都保留在盒子内部，符合w3c关于垂直边距叠加的说明。但是不要在现有的项目中简单地用这些代码替换你的clearfix规则，否则可能会与你原来为了解决边距重叠问题采取的解决方案产生冲突。

overflow

在众多关于清除浮动的讨论中，出现了overflow:hidden的方法，并且这种方法总是被“如果你把绝对定位元素置于div内部，这些元素（超出的部分）将会被隐藏”的观点击败。但事实并非如此。overflow:hidden 会修剪相对定位（position:relative）的元素，但并不总是会隐藏绝对定位元素。这是因为是否隐藏绝对定位元素实际上取决其包含块（containing block）：

10.1 "containing block" 的定义：

4. If the element has 'position:absolute', the containing block is established by the nearest ancestor with a 'position' of 'absolute', 'relative', or 'fixed'. …

翻译：如果一个元素有"position:absolute"的定义，则其包含块由最近的拥有"position:absolute|relative|fixed"属性的祖先元素确定。…

这意味着一个带有overflow:hidden样式的盒子，它所包含的绝对定位子元素如果溢出，并不会被隐藏——除非该绝对定位元素的包含块（containing block）就是这个盒子本身或位于该盒子内部。也就是说，如果这个绝对定位元素的包含块的层级高于拥有overflow:hidden样式的盒子，那么这个盒子里面的绝对定位元素不会被截断或隐藏。

作者提供了一个demo 页面演示这个原理（页面上的wrapper设定了overflow:hidden，但是绝对定位的子元素box1却显示在了wrapper外面的左上角，并没有被隐藏）。

更好的选择

如果你可以对包含浮动的元素应用宽度，那么更好的办法是用下面的样式来清除浮动：

display: inline-block;
width: <any explicit value>;

引申阅读

• Contained Floats, enclosing floats with pure CSS known as the clearfix technique
• How To Clear Floats Without Structural Markup
• The New Clearfix Method
• 10.1 Definition of "containing block"

关于作者: Thierry Koblentz 是 Yahoo! 的一位前端工程师。他负责的项目有 TJK Design 和 ez-css.org. 你可以在twitter上follow他： @thierrykoblentz .

相关日志

• 2009-06-22 -- Whatever:hover – 无需javascript让IE支持丰富伪类
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-12 -- 自适应的多列图文混排改进
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-30 -- webkit中BFC元素临近浮动元素时的边距bug
• 2010-10-22 -- HTML验证的价值探讨【译】
• 2009-12-21 -- 前台开发从头说起：理解css盒模型
• 2009-12-16 -- 前台开发从头说起：谈谈CSS选择符
• 2009-12-15 -- 前台开发从头说起：关于web标准化

18. HtmlHelper 扩展

首先，参考一下 Rob Conery 的这篇文章，我完全同意他的观点，你应该为每种情况创建 Helper 方法，此外我还建议你像 ASP.NET MVC 团队那样为可重用的 UI 元素创建 Helper 方法，但是对于在哪里放置我们正在实践的这些方法，我有不同的建议。

应用程序开发者

只为你需要在多个视图中重复使用的HtmlHealper创建单独的扩展方法。对于只在一个视图中使用的帮助方法，你可以为整个视图创建一个Helper类，然后创建一个HtmlHelper来返回这个视图Helper类，而把只在这个视图中使用的扩展方法作为类内部的方法。（这部分未按原文翻译，请自行参照原文）例如：

public class DashboardHtmlHelper {
    private readonly HtmlHelper _htmlHelper;

    public DashboardHtmlHelper(HtmlHelper htmlHelper) {
        _htmlHelper = htmlHelper;
    }

    public string DoThis() {
        //Your Code
    }

    public string DoThat() {
        //Your Code
    }
}

public static class HtmlHelperExtension {
    public static DashboardHtmlHelper Dashboard(this HtmlHelper htmlHelper) {
        return new DashboardHtmlHelper(htmlHelper);
    }
}

然后在视图中这样调用：

<%= Html.Dashboard().DoThis() %>

UI 组件开发人员

如果你在开发的是可以在多个 ASP.NET MVC 应用程序中重用的 UI 组件系列，你可以像上面那样为你的整个系列组件创建一个单一名字的Helper。假如你开发的是商业组件，那你可以用你的公司名字来为这个单一的Helper命名，然后在这个Helper中添加方法。否则很容易出现方法的命名冲突。

要是你正在学习 MVCContrib.org 的做法，为 IViewDataContainer 做扩展的话，道理也是一样的。

19. Html编码

在从用户端获取信息的任何情况下，总是使用 Html.Encode(“User Input”) 来编码文本节点，用 Html.AttributeEncode(“User Input”) 来编码Html 元素属性。

20. 不要把Javascript脚本放在你的视图中

不要把你的javascript脚本和html混杂在一起，创建一个单独的 js 文件，把脚本代码放在里面。有时候你可能需要在你的 javascript 代码中传递视图数据，这种特殊的情况下，也只把初始化代码放在视图中。例如，你正在开发 web 2.0 风格的应用，你需要在这个应用中传递 ajax 方法的url，并且需要在 javascript 脚本中传递一些其它的模型数据，这种情况下，你可以参考下面的方式：

视图：

<div id="sideBar" class="column"></div>
        <script type="text/javascript">
            $(document).ready(function(){
                Story.init('<%= Model.UrlFormat %>', '<%= Url.NoIcon() %>', <%= Model.PageCount %>, <%= Model.StoryPerPage %>, <%= Model.CurrentPage %>, '<%= Model.SelectedTab %>', '<%= Model.SelectedOrderBy %>');
            });
        </script>
    </div>
</asp:Content>

Javascript：

var Story = {
    _urlFormat: '',
    _noIconUrl: '',
    _pageCount: 0,
    _storyPerPage: 0,
    _currentPage: 0,
    _currentTab: '',
    _currentOrderBy: '',

    init: function(urlFormat, noIconUrl, pageCount, storyPerPage, currentPage, currentTab, currentOrderBy) {
        Story._urlFormat = urlFormat;
        Story._noIconUrl = noIconUrl;
        Story._pageCount = pageCount;
        Story._storyPerPage = storyPerPage;
        Story._currentPage = currentPage;
        Story._currentTab = currentTab;
        Story._currentOrderBy = currentOrderBy;

        //More Codes
    }
}

这里要为不太熟悉上面的 javascript 的同学解释一下，这是一个在javascript中创建静态类的示例代码。对了，我还差点忘了提一点，永远不要在你的javascript文件中硬编码 ajax 方法的url，虽然 Rob Conery 和 Phil Haack 在他们的教程中是这样干的。这是一个很不好的方式，它破坏了 ASP.NET 路径重写的优雅性。

21. 使用 jQuery 和 jQuery UI

使用 jQuery 和 jQuery UI，它是最好的js库，并且可以使用 Google CDN 托管服务来加载这些库（对于国内用户，如果使用 google 托管的库一定要有承担风险的准备，具体原因嘛，看看国内6月24日左右的IT新闻就知道了）。

<link type="text/css" href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.1/themes/{YOUR Prefered Theme}/jquery-ui.css" rel="stylesheet"/>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.1/jquery-ui.js"></script>

还有一种更好的方式：

<link type="text/css" href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.1/themes/{YOUR Prefered Theme}/jquery-ui.css" rel="stylesheet"/>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
    google.load("jquery", "1.3.2");
    google.load("jqueryui", "1.7.1");
</script>

以上就是这一次的全部内容。

最后，我要祝贺 ASP.NET MVC 团队开发了如此杰出的框架，尤其是他们从社区接受反馈的方式。我希望能用这个框架开发出更多杀手级的应用（注：杀手级的应用程序，一般指极其优秀的应用程序，这类程序超越了语言本身，比语言更有吸引力而且能增加语言的吸引力）。

相关日志

• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-07-01 -- ASP.NET MVC 最佳实践（二）
• 2009-06-28 -- ASP.NET MVC 最佳实践（一）
• 2009-04-13 -- [翻译]ASP.NET MVC动手实验1-3：开发ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手实验1-2：创建ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手系列1-1：ASP.NET MVC概述
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-25 -- 借助jQuery和Google分析服务的事件追踪深入了解用户行为【译】

15. 关于路由的思考

如果你在开发的是一个纯 ASP.NET MVC 的应用程序，可以先关闭已有的路由文件检查，这样可以去除不必要的文件系统检查。如果你这样做了，那么就还需要考虑另外的一些事情。请记住如果你的应用程序运行于 IIS 7集成模式，那么 ASP.NET 应用程序将会拦截所有的请求，不管文件的后缀名是什么。所以你必须要在过滤列表中加一些东西，以便让 ASP.NET MVC 应用程序不处理它们。这其中可能包括静态文件，例如 html、htm、文本文件(尤其是robots.txt)、favicon.ico、脚本、图片和css等等。这也是我在第一部分第2节中提到不喜欢默认文件结构的原因之一。以下是我为 IIS7 定制的路由定义标准模板：

_routes.Clear();

// Turns off the unnecessary file exists check
_routes.RouteExistingFiles = true;

// Ignore text, html, files.
_routes.IgnoreRoute("{file}.txt");
_routes.IgnoreRoute("{file}.htm");
_routes.IgnoreRoute("{file}.html");

// Ignore axd files such as assest, image, sitemap etc
_routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

// Ignore the assets directory which contains images, js, css & html
_routes.IgnoreRoute("assets/{*pathInfo}");

// Ignore the error directory which contains error pages
_routes.IgnoreRoute("ErrorPages/{*pathInfo}");

//Exclude favicon (google toolbar request gif file as fav icon which is weird)
_routes.IgnoreRoute("{*favicon}", new { favicon = @"(.*/)?favicon.([iI][cC][oO]|[gG][iI][fF])(/.*)?" });

//Actual routes of my application

接下来是我的一些不同于手册指南的个人偏好。默认情况下 ASP.NET MVC 产生的 url 形如 {controller}/{action}，在你开发一个多模块的应用程序是这是不错的选择，但是对于一些很小的应用程序，我通常喜欢从 url 中去掉控制器(controller)只留下方法名(action name)。如此一来，原来的“www.yourdomain.com/Story/Dashboard” 及 “www.yourdomain.com/Membership/Signin” 就会变成 “www.yourdomain.com/Dashboard” 和“www.yourmain.com/Signin”。所以我要添加一些新路由：

_routes.MapRoute("SignUp", "SignUp", new { controller = "Membership", action = "SignUp" });
_routes.MapRoute("SignIn", "SignIn", new { controller = "Membership", action = "SignIn" });
_routes.MapRoute("ForgotPassword", "ForgotPassword", new { controller = "Membership", action = "ForgotPassword" });
_routes.MapRoute("SignOut", "SignOut", new { controller = "Membership", action = "SignOut" });
_routes.MapRoute("Profile", "Profile", new { controller = "Membership", action = "Profile" });
_routes.MapRoute("ChangePassword", "ChangePassword", new { controller = "Membership", action = "ChangePassword" });

_routes.MapRoute("Dashboard", "Dashboard/{tab}/{orderBy}/{page}", new { controller = "Story", action = "Dashboard", tab = StoryListTab.Unread.ToString(), orderBy = OrderBy.CreatedAtDescending.ToString(), page = 1 });
_routes.MapRoute("Update", "Update", new { controller = "Story", action = "Update" });
_routes.MapRoute("Submit", "Submit", new { controller = "Story", action = "Submit" });

_routes.MapRoute("Home", "{controller}/{action}/{id}", new { controller = "Home", action = "Index", id = string.Empty });

16. 如果需要的话，创建新的ActionResult

ASP.NET MVC 包含有很多种用于不同目的的 ActionResult，但我们仍有可能会需要新的 ActionResult。例如xml、rss、atom等等。在这种情况下，我的建议是不要使用通用的 ContentResult， 而是创建一种新的 ActionResult. MVCContrib 项目中有一个 XmlResult，你可以用它来返回 xml，但是不支持 feed。显然依靠它来将未知对象转换为 rss/atom 是很困难的，这时你就可以创建一个定义ActionResult的模型。例如：

public class AtomResult : ActionResult {
    public AtomResult(string siteTitle, string feedTitle, IEnumerable<IStory> stories) {
        SiteTitle = siteTitle;
        FeedTitle = feedTitle;
        Stories = stories;
    }

    public string SiteTitle {
        get;
        private set;
    }

    public string FeedTitle {
        get;
        private set;
    }

    public IEnumerable<IStory> Stories {
        get;
        private set;
    }

    public override void ExecuteResult(ControllerContext context) {
        string xml = Build(context);

        HttpResponseBase response = context.HttpContext.Response;
        response.ContentType = "application/atom+xml";
        response.Write(xml);
    }
}

然后在控制器中就可以这样写：

[AcceptVerbs(HttpVerbs.Get), OutputCache(CacheProfile = "Atom")]
public ActionResult Shared() {
    IEnumerable<stories> stories = GetSharedStories();

    return new AtomResult("My Site", "My shared stories in atom", stories);
}

17. 把你的视图拆分为多个视图控件

如果你的视图文件变得越来越大，那你可以考虑把它拆分为多个视图控件。至于视图空间是否在多个页面中重用，并没有关系。因为这样做可以让真正的视图文件变得更加具有可读性。考虑一下下面的视图：

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
    My Secret App : Dashboard
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
    <div id="heading"></div>
    <div class="columns">
        <div id="main" class="column">
            <div id="storyListTabs" class="ui-tabs ui-widget ui-widget-content ui-corner-all">
                <% Html.RenderPartial("TabHeader", Model);%>
                <div id="tabContent" class="ui-tabs-panel ui-widget-content ui-corner-bottom">
                    <div id="storyList">
                        <% Html.RenderPartial("SortBar", Model);%>
                        <div class="clear"></div>
                        <% Html.RenderPartial("NoLinkMessage", Model);%>
                        <form id="update" action="<%= Url.Update()%>" method="post">
                            <% Html.RenderPartial("List", Model);%>
                            <% Html.RenderPartial("ActionBar", Model);%>
                            <% Html.RenderPartial("Pager", Model);%>
                        </form>
                    </div>
                </div>
            </div>
            <%Html.RenderPartial("Submit", new StorySubmitViewModel());%>
        </div>
        <div id="sideBar" class="column"></div>
    </div>
</asp:Content>

继续阅读：《ASP.NET MVC 最佳实践（四）》

相关日志

• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-01 -- ASP.NET MVC 最佳实践（二）
• 2009-06-28 -- ASP.NET MVC 最佳实践（一）
• 2009-04-13 -- [翻译]ASP.NET MVC动手实验1-3：开发ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手实验1-2：创建ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手系列1-1：ASP.NET MVC概述
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-25 -- 借助jQuery和Google分析服务的事件追踪深入了解用户行为【译】

7. 不要在控制器中使用HttpContext类及其派生类

在你的控制器中不要引用到HttpContext以及它的派生类。这让你能比较容易地进行控制器的单元测试。如果你需要访问与HttpContext相关的对象比如User、QueryString、Cookie等，你可以使用自定义的行为过滤器（博客园的老赵有一篇文章对这一条进行了深入的论述，并提出了自己的解决方案，建议阅读）或者创建一些接口和容器，并把它传入控制器的构造函数。例如，下面的路由：

routes.MapRoute(
    "Dashboard",
    "Dashboard/{tab}/{orderBy}/{page}",
    new {
        controller = "Story",
        action = "Dashboard",
        tab = StoryListTab.Unread.ToString(),
        orderBy = OrderBy.CreatedAtDescending.ToString(),
        page = 1
    }
);

而控制器的行为方法则定义为：

[AcceptVerbs(HttpVerbs.Get),OutputCache(CacheProfile = "Dashboard"),UserNameFilter]
public ActionResult Dashboard(string userName, StoryListTab tab, OrderBy orderBy, int? page) {
}

UserNameFilter这个过滤器负责传递UserName：

public class UserNameFilter : ActionFilterAttribute {
    public override void OnActionExecuting(ActionExecutingContext filterContext) {
        const string Key = "userName";

        if (filterContext.ActionParameters.ContainsKey(Key)) {
            if (filterContext.HttpContext.User.Identity.IsAuthenticated) {
                filterContext.ActionParameters[Key] = filterContext.HttpContext.User.Identity.Name;
            }
        }

        base.OnActionExecuting(filterContext);
    }
}

[更新：一定要明确你已经对控制器或者是对控制器中的行为添加了 Authorize 属性，参见原文评论。]

8. 用行为控制器来转换行为方法参数

用行为过滤器来把传入值转换为你的控制器行为方法参数，再看一下 Dashboard方法的代码，我们以 Enum 类型接受 tab 和 orderBy这两个参数。

[AcceptVerbs(HttpVerbs.Get), OutputCache(CacheProfile = "Dashboard"), StoryListFilter]
public ActionResult Dashboard(string userName, StoryListTab tab, OrderBy orderBy, int? page) {
}

过滤器 StoryListFilter 将负责把它由 路由的值/查询字符串 转换为适当的数据类型。

public class StoryListFilter : ActionFilterAttribute {
    public override void OnActionExecuting(ActionExecutingContext filterContext) {
        const string TabKey = "tab";
        const string OrderByKey = "orderBy";

        NameValueCollection queryString = filterContext.HttpContext.Request.QueryString;

        StoryListTab tab = string.IsNullOrEmpty(queryString[TabKey]) ?
                            filterContext.RouteData.Values[TabKey].ToString().ToEnum(StoryListTab.Unread) :
                            queryString[TabKey].ToEnum(StoryListTab.Unread);

        filterContext.ActionParameters[TabKey] = tab;

        OrderBy orderBy = string.IsNullOrEmpty(queryString[OrderByKey]) ?
                            filterContext.RouteData.Values[OrderByKey].ToString().ToEnum(OrderBy.CreatedAtDescending) :
                            queryString[OrderByKey].ToEnum(OrderBy.CreatedAtDescending);

        filterContext.ActionParameters[OrderByKey] = orderBy;

        base.OnActionExecuting(filterContext);
    }
}

你也可以用自定义模型绑定器来达到同样的目的。如果要那样做的话，你需要为每个枚举创建一个独立的模型绑定器，而不是用一个行为过滤器来处理所有的枚举参数。用模型绑定器还有一个问题，一旦你注册了一个类型，在行为中它就总是被使用，而行为过滤器则是可以根据需要选择使用的。

9. 行为过滤器的位置

如果你要对你的控制器的所有行为方法应用同一个行为过滤器，你可以把这个过滤器放在控制器的定义上而不必给每个行为方法应用。如果你要对你的所有控制器应用同一个行为过滤器，你应该创建一个基控制器，对它应用该过滤器，并让所有的控制器继承这个基控制器。例如 story 控制器应该只在用户已经登陆的情况下才可以使用，并且我们需要把当前用户的用户名传入 story 控制器下的方法，另外Story控制器应该压缩返回的数据：

[Authorize, UserNameFilter]
public class StoryController : BaseController {
}

[CompressFilter]
public class BaseController : Controller {
}

但是如果继承的层次达到或者高于2层，应该另找方法来应用过滤器。最新的 Oxite 代码里有一些非常出色的动态应用过滤器的方法，我强烈推荐你去看一下。

10. 小心使用UpdateModel

我要再次强调 Justin Ethredge 在他的文章中已经提过的这个问题，开发中一定小心，避免陷进UpdateModel的陷阱里去。

11.控制器不要包含任何域逻辑

控制器应该只负责：

• 验证输入
• 调用Model层来为显示视图准备数据
• 返回视图或者跳转到另一个行为

如果你在控制器中坐了其它的事情，那就说明你把它们放错了地方。你在控制器中坐的这些事情或许更应该交给模型去处理。只要你遵守了这条规则，你的每个控制器方法代码应该不会超过20到25行。 Ian Cooper 有一篇很棒的文章《Skin Controller Fat Model》，有空的时候你一定要读一下。

12. 避免使用 ViewData，尽量使用ViewData.Model

依赖于数据字典不仅使你的代码难以重构，而且你还不得不在试图中编写转换代码。实际上即使你给你的控制器的每个方法都单独编写一个类作为数据模型，那也是完全可以的。如果你觉得编写这些视图数据模型类是一项非常乏味的工作的话，你可以使用 MVCContrib 项目中 ViewDataExtensions，它包含一些用于返回强类型对象的不错的扩展。但是如果你的视图数据的数据字典中包含了多个数据类型的话，你还是没办法摆脱数据字典和他的字符串名。

13. 用 PRG 模式来修改数据

Tim Barcz, Matt Hawley, Stephen Wather 甚至 Scott Gu 都写了这方面的文章，你可以在 这里、这里、这里和这里找到它们。这个模式的一个问题是当一项验证失败或者发生任何错误的时候，你不得不把ModelState复制到TempData里面。如果你是手动来做这件事，请不要再那样做了，你可以用行为过滤器自动处理它，就像下面这样：

[AcceptVerbs(HttpVerbs.Get), OutputCache(CacheProfile = "Dashboard"), StoryListFilter, ImportModelStateFromTempData]
public ActionResult Dashboard(string userName, StoryListTab tab, OrderBy orderBy, int? page)
{
    //Other Codes
    return View();
}

[AcceptVerbs(HttpVerbs.Post), ExportModelStateToTempData]
public ActionResult Submit(string userName, string url)
{
    if (ValidateSubmit(url))
    {
        try
        {
            _storyService.Submit(userName, url);
        }
        catch (Exception e)
        {
            ModelState.AddModelError(ModelStateException, e);
        }
    }

    return Redirect(Url.Dashboard());
}

还有行为过滤器的代码：

public abstract class ModelStateTempDataTransfer : ActionFilterAttribute {
    protected static readonly string Key = typeof(ModelStateTempDataTransfer).FullName;
}

public class ExportModelStateToTempData : ModelStateTempDataTransfer {
    public override void OnActionExecuted(ActionExecutedContext filterContext) {
        //Only export when ModelState is not valid
        if (!filterContext.Controller.ViewData.ModelState.IsValid) {
            //Export if we are redirecting
            if ((filterContext.Result is RedirectResult) || (filterContext.Result is RedirectToRouteResult)) {
                filterContext.Controller.TempData[Key] = filterContext.Controller.ViewData.ModelState;
            }
        }

        base.OnActionExecuted(filterContext);
    }
}

public class ImportModelStateFromTempData : ModelStateTempDataTransfer {
    public override void OnActionExecuted(ActionExecutedContext filterContext) {
        ModelStateDictionary modelState = filterContext.Controller.TempData[Key] as ModelStateDictionary;

        if (modelState != null) {
            //Only Import if we are viewing
            if (filterContext.Result is ViewResult) {
                filterContext.Controller.ViewData.ModelState.Merge(modelState);
            } else {
                //Otherwise remove it.
                filterContext.Controller.TempData.Remove(Key);
            }
        }

        base.OnActionExecuted(filterContext);
    }
}

MVCContrib 项目也有这个功能，但是我不喜欢他们在用一个单独类来处理的方式，我喜欢对“哪个方法输出”和“哪个方法输入”有更多的控制权。

14. 为你的视图模型创建父类层并用行为过滤器来构成公共部分

为你的视图模型类编写一个父类层，并用过滤器来构成它的公共部分。例如我正在开发的这个非常小的应用程序，我需要知道用户是否已经认证，已及用户名。

public class ViewModel {
    public bool IsUserAuthenticated {
        get;
        set;
    }

    public string UserName {
        get;
        set;
    }
}

还有行为过滤器的代码：

public class UserNameFilter : ActionFilterAttribute {
    public override void OnActionExecuting(ActionExecutingContext filterContext) {
        const string Key = "userName";

        if (filterContext.ActionParameters.ContainsKey(Key)) {
            if (filterContext.HttpContext.User.Identity.IsAuthenticated) {
                filterContext.ActionParameters[Key] = filterContext.HttpContext.User.Identity.Name;
            }
        }

        base.OnActionExecuting(filterContext);
    }
}

public class ViewModelUserFilter : ActionFilterAttribute {
    public override void OnActionExecuted(ActionExecutedContext filterContext) {
        ViewModel model;

        if (filterContext.Controller.ViewData.Model == null) {
            model = new ViewModel();
            filterContext.Controller.ViewData.Model = model;
        } else {
            model = filterContext.Controller.ViewData.Model as ViewModel;
        }

        if (model != null) {
            model.IsUserAuthenticated = filterContext.HttpContext.User.Identity.IsAuthenticated;

            if (model.IsUserAuthenticated) {
                model.UserName = filterContext.HttpContext.User.Identity.Name;
            }
        }

        base.OnActionExecuted(filterContext);
    }
}

正如你所看到的，如果在控制器里预先设定它的话，它并没有替换模型，而是在它发现模型与它符合的时候，才作为控制器的公共部分起作用。另一个好处是，由于视图只依赖于父类层，你可以不必返回具体的model，而只需要返回 View()。

继续阅读：《ASP.NET MVC 最佳实践（三）》

相关日志

• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-06-28 -- ASP.NET MVC 最佳实践（一）
• 2009-04-13 -- [翻译]ASP.NET MVC动手实验1-3：开发ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手实验1-2：创建ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手系列1-1：ASP.NET MVC概述
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-25 -- 借助jQuery和Google分析服务的事件追踪深入了解用户行为【译】

1. 创建UrlHelper的扩展方法来生成url

尽量避免以字符串方式直接传递controller, action 或者 route name，最好是为创建为UrlHelper创建扩展方法来封装url。例如：

public static class UrlHelperExtension {
    public static string Home(this UrlHelper helper) {
        return helper.Content("~/");
    }

    public static string SignUp(this UrlHelper helper) {
        return helper.RouteUrl("Signup");
    }

    public static string Dashboard(this UrlHelper helper) {
        return Dashboard(helper, StoryListTab.Unread);
    }

    public static string Dashboard(this UrlHelper helper, StoryListTab tab) {
        return Dashboard(helper, tab, OrderBy.CreatedAtDescending, 1);
    }

    public static string Dashboard(this UrlHelper helper, StoryListTab tab, OrderBy orderBy, int page) {
        return helper.RouteUrl("Dashboard", new { tab = tab.ToString(), orderBy = orderBy.ToString(), page });
    }

    public static string Update(this UrlHelper helper) {
        return helper.RouteUrl("Update");
    }

    public static string Submit(this UrlHelper helper) {
        return helper.RouteUrl("Submit");
    }
}

这样，如果在你的视图中有类似这样的代码：

    <%= Html.ActionLink("Dashboard", "Dashboard", "Story") %>
    <a href="<%= Url.RouteUrl("Profile")%>">Profile</a>

你就可以用下面的这种方式来代替它们：

<a href="<%= Url.Dashboard() %>">Dashboard</a>
<a href="<%= Url.Profile() %>">Profile</a>

在控制器里也可以用，原来的代码：

return RedirectToAction(
    "Dashboard",
    "Story",
    new {
        tab = StoryListTab.Favorite,
        orderBy = OrderBy.CreatedAtAscending,
        page = 1
    }
);

可以写成：

return Redirect(Url.Dashboard(StoryListTab.Favorite,
                                OrderBy.CreatedAtAscending, 1));

当然了，你也可以使用 future assembly 中的强类型版本来获得控制器、方法以及参数值，或者创建你自己的强类型版本以免将来进行重构时太过于痛苦，但是请一定记住，它没有官方支持并且将来有可能会发生改变。上面的方式也可以和强类型版本搭配使用。当然“另外增加一个间接层”（Scott Ha 喜欢用的引语）有一些好处，在编写单元测试的时候还有一个好处是你只需处理 RedirectResult 而无须同时处理 RedirectResult 和 RedirectToRouteResult。

2. Create Extension Method of UrlHelper to map your JavaScript, Stylesheet and Image Folder

默认情况下 ASP.NET MVC 创建Content、Scripts文件夹来做这些事，这一点我不喜欢，我更喜欢下面的这种文件夹结构，这样在IIS里我可以只让静态文件缓存在Assets文件夹而不是多个文件夹：

• Assets
• +images
• +scripts
• +stylesheets

无论是结构是什么样的，还是要为UrlHelper创建一些扩展方法来映射这些文件夹，以便你在视图中可以很方便地指向它们，这样以后如果你要改变目录结构，你就无须做大量查找替换的工作。我还建议你为所有经常在视图中用到的资源创建UrlHelper的扩展方法。例如：

public static string Image(this UrlHelper helper, string fileName) {
    return helper.Content("~/assets/images/{0}".FormatWith(fileName));
}

public static string Stylesheet(this UrlHelper helper, string fileName) {
    return helper.Content("~/assets/stylesheets/{0}".FormatWith(fileName));
}

public static string NoIcon(this UrlHelper helper) {
    return Image(helper, "noIcon.png");
}

然后当需要用到这些路径的时候，原来的代码

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

就可以写成这样：

<link href="<%= Url.Stylesheet("site.css")%>" rel="stylesheet" type="text/css" />

3. 中使用启动加载器

我在以前的文章中已经提到过这一点，总的来说就是：如果你要在 Global.asax 的 Application_Start 中做很多处理，比如 注册路由规则(Routers)、注册控制器工厂(Controller Factory)、模型绑定(Model Binders)、视图引擎(View Engine)、启动程序级的特定后台服务或者为特定部分创建独立任务等，那就用启动加载器来执行这些操作。这会让你的代码更简洁，更可测。这一点在用 ASP.NET MVC 构建门户级应用时尤其有用，因为这类应用中的每个模块都可能有一些不影响到其他模块的启动初始化操作。但是如果你只是开发一个小应用，上面提到的这些对你来说都不是问题，你当然也可以继续用默认的 global.asax。

4. 不要硬编码对依赖注入容器的调用，用通用服务定位器来代替。

不要让任何特定的依赖注入容器(DI Container)打乱你的代码，更好的办法是使用通用服务定位器(Common Service Locator)，它是对底层依赖注入进行的抽象，已经支持几乎所有流行的依赖注入容器，它让你可以任意替换底层的依赖注入对象而无须修改代码，因为每个依赖注入容器都具有一些不同于其它容器的特性。Tim Barcz 最近写了一篇关于这个话题的很棒的文章，我不太明白他为什么没有提到我们对我们偏爱的依赖注入容器有多痴迷。通用服务定位器对绝大部分常用情景都提供了支持，而对一些特殊情况比如对已实体化对象的依赖注入，我印象里有 StructureMap、Ninject 和 Unity，你可以调用静态方法 ServiceLocator.Current.GetInstance 来代替。 通用服务定位器 是 Jeremy D Miller 发起的 依赖注入容器开发者(the DI Containers creators)的集体作品。

用通用服务定位器创建控制器工厂非常容易：

public class CommonServiceLocatorControllerFactory : DefaultControllerFactory {
    protected override IController GetControllerInstance(Type controllerType) {
        return (controllerType == null) ? base.GetControllerInstance(controllerType) : ServiceLocator.Current.GetInstance(controllerType) as IController;
    }
}

我希望 MVCContrib 的成员们也用这样的方式，而不是为每个容器创建一个独立的控制器工厂。

5. 用恰当的的AcceptVerbs属性来修饰你的控制器方法

ASP.NET MVC 比 Web Forms 更容易遭受攻击。所以务必让对数据进行修改的控制器方法只接受 Post 方式请求（HttpVerbs.Post）。如果安全对你来说至关重要，你还可以用 ValidateAntiForgeryToken 或者 Captcha。我强烈推荐 Derik Whittaker 写的一篇 很好的文章 以及视频介绍了怎么把 reCaptcha 整合到 ASP.NET MVC 应用程序（作者注：不要错过了 DimeCasts.net 的另一个短片，我从中学到了很多）。我的经验法则是对所有数据修改方法使用 HttpVerbs.Post，对所有数据读取操作使用 HttpVerbs.Get。

6. 用OutputCache修饰你的频繁调用的操作方法

当你需要返回不频繁更新的数据时使用 OutputCache 属性，最常见的例子是首页、Feed等。你在返回Html以及Json数据类型的方法中都可以使用这个属性。在使用的时候，注意只指定CacheProfile参数，不要指定任何其它东西，用 web.config 输出缓存控制节可以很好地调整它。例如：

[AcceptVerbs(HttpVerbs.Get), OutputCache(CacheProfile = "Dashboard")]
public ActionResult Dashboard(string userName, StoryListTab tab, OrderBy orderBy, int? page) {
}

在 web.config 文件中的配置：

<system.web>
    <caching>
        <outputCacheSettings>
            <outputCacheProfiles>
                <clear/>
                <!-- 15 Seconds -->
                <add
                    name="Dashboard"
                    duration="15"
                    varyByParam="*"
                    location="Client"
                    />
            </outputCacheProfiles>
        </outputCacheSettings>
    </caching>
</system.web>

请继续阅读：《ASP.NET MVC 最佳实践（二）》

相关日志

• 2009-07-08 -- ASP.NET MVC 最佳实践（四）
• 2009-07-07 -- ASP.NET MVC 最佳实践（三）
• 2009-07-01 -- ASP.NET MVC 最佳实践（二）
• 2009-04-13 -- [翻译]ASP.NET MVC动手实验1-3：开发ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手实验1-2：创建ASP.NET MVC应用
• 2009-04-09 -- [翻译]ASP.NET MVC动手系列1-1：ASP.NET MVC概述
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-10 -- CSS边框实现“无图化”设计【译】
• 2010-10-31 -- CSS技巧:如何避免IE6中的"浮动下坠"【译】
• 2010-10-25 -- 借助jQuery和Google分析服务的事件追踪深入了解用户行为【译】