清晨

前三篇文章中，明确了栅格系统的设计细节和适用范围。这一篇将集中讨论960栅格系统的技术实现。

Blueprint的实现

Blueprint是一个完整的CSS框架，栅格系统是它的一部分功能。我们来看demo页面：

采用浮动来实现布局，简单明了

950两侧没有margin, 最后一列的class需要加上last

采用额外标签来清除浮动

960.gs的实现

谈到960栅格系统，不得不提960.gs. Nathan Smith在这篇文章中，详细阐述了他的想法和设计思路。这里有个demo页面，核心代码很简单：

以下为引用的内容：

上面就构建了三栏布局：

有意思的几点：

margin是均匀放在950两侧的

所有grid除了宽度不同，左右边距都一致margin: 0 10px;

代码简单清晰，起始和结束列不需要添加额外class

很明显，Blueprint和960.gs都是采用浮动来实现布局的，主容器需要添加额外标签来清除浮动(可以参考这里)。当然，这也不是什么大问题，请看这篇文章的总结，不添加额外标签也可以清除浮动。

YUI的实现

接着来看大名鼎鼎的YUI Grids CSS. YUI的CSS框架由三个文件组成：

以下为引用的内容：

reset.css - 样式重置

fonts.css - 版式字体控制

grids.css - 栅格系统

我们从demo开始：

注意，demo链接中的宽度是750的，但我们只要将

目前尚未严格遵守栅格系统，如果重构的话，宽度方向可以考虑采用下面的栅格布局（只考虑页面主体部分，忽略高度的比例）：

（图1）

纷乱的高度世界

我们来看下图1左上角。左上角部分目前的宽度为256px, 重构的话可以将宽度缩小到230px以符合栅格（不可避免的要调整内容，比如人气宝贝中将只能放下3张图片）。来仔细看下高度方向：

（图2）

高度方向的布局是：90 : 117 : 100, 第一个间隔是8, 总高度为325. 很明显，高度方向没有任何栅格化的迹象。实际上，

即便是严格遵守栅格系统的Yahoo!首页，高度方向上也没有严格栅格化。

这究竟是为何？

一切皆有可能

我们缩小关注点：

（图3）

上图中，图像的大小是70 x 70, 刚好是24列960栅格系统两列的宽度。对于右边的文字，采取了如下样式：

font-size:　12px;

line-height:　150%;　/*　12　x　150%　=　18px　*/

中文字体是宋体，line-height的计算值是18px. 注意图3中文字部分可视区域的高度为65, 上下各有4px和1px的间隙。为什么会产生这么奇怪的间隙呢？我们来看下图：

（图4）

从上图中我们可以得知，12px的宋体中文字，实际高度只有11px.line-height减去11多出来的高度，则“均匀”分布在上下间隙中（如果多出来的高度为偶数，则上下均分；为奇数时，上面比下面多1px）。这样，对于70px的高度来说，要布局4行文字时，假设行高多出来的上半部分为x, 下半部分为y, 在最理想的情况下，应该满足以下公式：

11　*　4　+　4　*　x　+　3　*　y　=　70

x　=　y　或　x　=　y　+　1

不难推出，x最理想的整数解为4. 从而line-height为 4 + 11 + 3 = 18. 因此：

对于24列960栅格系统来说，如果要在高度方向上实现栅格，font-size为12px时，line-height的最佳取值是18px(150%).

追求完美点话，还可以将文字部分margin-top: -1px, 使得65上下的间隙为3和2.

至此，我们可以初步判断：

高度方向上是有可能严格栅格化的。一切皆有可能！

然而，现实总那么残酷

（图5）

上图中的标题高度为22, 这在24列960栅格系统中是无法对齐的。而且总高度为100, 在24列960栅格系统中也不存在（110才可以）。或许高度方向上我们可以细化行宽为20, 但依旧没法解决上面两个问题（22是明显不能解决的，而对于100px的高度，也无法通过细化行宽来解决。可选高度永远是10的奇数倍，如果进一步细化， 小于10后，会变得非常繁琐，没什么实际应用价值）

宽度世界里会好些吗

（图6）

上面是Yahoo!首页上的两个小模块，我都不想去标注模块里面的布局宽度了（因为一点都不符合24列960栅格系统）。宽度世界里，和高度世界一样充满希望但现实却残酷无比。

银弹是不存在的

栅格系统是美好的。但如果我们一味地追求将所有设计都栅格化（必须承认我曾有这个幻想），则立刻会陷入地狱一般的黑暗中。这篇文章中的艰难尝试（我 分析了20多个小模块），让我突然醒悟到一个粒度问题：任何设计都有适用范围，超出最佳适用范围，强行使用只会带来无尽的烦恼。对于栅格系统（这里指所有 栅格系统，包括多种栅格系统混合使用的情景）来说，我觉得以下场景非常适合：

页面的总体宽度布局，比如两栏、三栏等布局

一些固定区块的尺寸，比如广告图片的尺寸

区块之间的间距，可以参考栅格系统的槽宽（Gutter）

一些可以栅格化的小区域，比如图3中的例子，暗合栅格往往能简化布局上的考虑

除了上面这些应用场景，强行使用栅格系统，往往会束手束脚，适得其反。这篇文章的目的，就是尝试用最啰嗦最费神貌似很科学实际很无聊的分析来指出栅 格系统应用时的粒度问题。在粒度问题上达成一致后，下一篇中我们将讨论栅格系统的技术实现，最后一篇则讨论栅格系统的压轴好戏：模块化开发。

研究网页栅格系统前，来看一组数据：

网站　　 　　 　首页页面宽度 px

Yahoo!　　　　 950

淘宝　　　　　   950

MySpace　　　  960

新浪　　　　　   950

网易　　　　　　960

Live Search　　 958

搜狐　　　　　    950

优酷　　　　　　960

AOL　　　　　　960

上面列举的都是Alexa全球排名前100的站点，它们的首页宽度为950px/960px. 除了微软的Live Search, 这些站点有个共同特点：页面结构较复杂，都可以认为是门户型网站。

再来看看Google, YouTube, Facebook, Flickr!, eBay等知名站点，它们的首页宽度没什么固定规律，共同的特点是：功能专一，页面结构相对简单。

根据上面的简单分析可以认为：当搭建页面结构复杂的门户型网站时，开发工程师们不约而同地都选择将页面宽度定为950px/960px.

这是一件很有趣的事情，为什么要选择这个宽度呢?这个宽度值究竟有什么魔力?

神奇的960

设计师们对苹果情有独衷。在 1024 x 768 的分辨率下，打开Firefox：

自然状态下，Firefox窗体的大小约为 974 x 650. 减掉左右两边7px的边框，网页的实际大小为上图中的红色部分，高宽为 960 x 650.

有趣的960就这样出现了。是的，可以认为一切就这么简单。栅格系统最早出现在平面设计领域，设计师们爱用苹果，苹果下浏览器的默认宽度为960px, 于是960就这么“自然”地出现了。

数字背后的奥妙

上面的“自然”出现，细究自然是不让人信服的。苹果系统的设计者们在没有喝醉酒的情况下选择了960，而不是其它什么1000之类的整数，自然另有奥妙。

科学界有很多问题都可以归结到数学问题上，我们也从数学着手：

960可以分解为2的6次方乘以3和5, 这使得960可以分割成以下宽度的整数倍：

以下为引用的内容：

2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 32, 40,

48, 60, 64, 80, 96, 120, 160, 192, 240, 320, 480

共26种（26 = 7 * 2 * 2 - 2, 减去2是去掉1和960自身），我们标记为：

以下为引用的内容：

N(960) = N(2^6 * 3 * 5) = 26

根据上面的算法，可以得到：

以下为引用的内容：

N(360) = N(2^3 * 3^2 * 5) = 22

N(480) = N(2^5 * 3 * 5) = 22

N(720) = N(2^4 * 3^2 * 5) = 28

N(750) = N(2 * 3 * 5^3) = 14

N(800) = N(2^5 * 5^2) = 16

N(960) = N(2^6 * 3 * 5) = 26

N(1000) = N(2^3 * 5^3) = 14

N(1024) = N(2^10) = 9

N(1440) = N(2^6 * 3^2 * 5) = 34

N(1920) = N(2^7 * 3 * 5) = 30

根据直觉(严格证明也不难，不过还是留给数学系的学生去证明吧)，我们得到一个有趣的结论：

要使得N(width)最大，width的取值有两个系列：

A系列： …, 320, 720, 1440, …

B系列： …, 480, 960, 1920, …

N越大，可组合的宽度值就越多。对栅格系统来说，这意味着越灵活!

目前绝大多数显示器都支持 1024 x 768 及其以上分辨率。为了有效的利用屏幕宽度同时保证栅格的灵活度，可以看出960是非常合适的。这样，在目前主流显示器下，960就成为网页栅格系统中的最佳宽度了。(也许不久的将来，将会流行1440)

细心的你也许会记得，本文开头列举的宽度值中，950也出现了好几次。950是怎么来的?和960是啥关系?这些疑问，请关注本系列的下一篇文章。

备注：本系列文章收集于网络，转载仅作学习使用。