刘钢的博客 - 我是UED » 页面实现

[转]让Web开发者事半功倍的8个网站

RichieLiu — Mon, 20 Jun 2011 01:19:41 +0000

1. Min.us: 上传图片的最简单方式

任何开发人员、设计师、网络管理员都必须跟客户和同事在线分享图片。Min.us的全部服务就是让你极度简单地上传图片：只需把图片拖拽到Min.us的网页里，图片就会保存在服务器上。并且自动生成短网址，这样你就可以通过这个网站分享图片了。

访问 Min.us

2. Wirify: 把任何网页转换成线框图

设计网站时线框图非常有用。Wirify是一个可以把任何网页立刻转换成线框图的书签工具，这样你就可以学习或应用到自己的工作中。

访问 Wirify

3. CSS Resetr: 查看和比较CSS resets

CSS resets是所有样式表的必需品，以在不同的浏览器之间渲染。2004年以来，已经发布了许多不同的CSS resets。那么，哪个才是最适合你的项目的呢?CSS Resetr可以让你比较最流行的resets对同一个网页的渲染效果。

访问 CSS Resetr

4. Head JS: 用2.30 kb的Javascript代码来提速你的网站

Head JS是一段简单、轻量的脚本代码，通过像加载图片一样加载其他脚本，让你的网站更快。Head JS能做许多工作使你的网站变得现代化：支持CSS3、动态CSS等等。

访问 Head js

5. Copy Paste Character: 轻松使用特殊字符

特殊字符处理起来很麻烦，因为键盘上没有，而且你不知道对应的ASCII码。当然，你可以找一份ASCII码表放在桌面上，或者使用一个叫做Copy Paste Character的服务：只需点击所选字符，就可以复制到你的剪贴板。

访问 Copy Paste Character

6. DB Designr: 在线生成数据库模式

这是一个非常棒的简单在线生成数据库模式的工具。无需创建账户，你可以用你的Google账户登入。(我觉得我们伯乐在线网站的读者都有Google账户!说不定你就是通过Google阅读器在阅读此文。)

访问 DB Designr (得翻墙)

7. Web 2 pdf convert: 把转换任意网页为PDF

Web2PDF Converter是一个很有用的工具，能把转换任意网页为PDF文件。非常好用：我已经转换了5个页面，所有地方都跟html上的版本完全一样。

访问web 2 pdf convert

8. ScriptSrc：轻轻松松地把html页面连接到JS库中

你是否已经厌倦了在网上寻觅最新的Javascript库标签?ScriptSrc.net收录了jQuery、 Mootools、 Prototype等所有最新的标签，只需单击就可以把它复制到你的浏览器剪贴板。

访问 ScriptSrc

再谈float菜单局中

RichieLiu — Mon, 21 Dec 2009 05:18:10 +0000

昨天用ucweb看到了goos发的一篇帖子：谁说Float菜单不可以水平居中，进去看了看，觉得方法有点繁琐了，用到了负边距，position:relativel; 和很少的一点hack。

我这里还有更简单的办法，先展示：
其实我外面应该再套一个div，但为了减少碳排放，舍弃。
DEMO1 DEMO2







float菜单局中一法



 Home
 News
 Store
 Group
 Community
 Help

其中最为关键的是这一句：

为了照顾较低版本IE，这里使用了条件注释，感觉在IE7以下中，display:inline;的作用就相当于inline-block;。根据上面代码进化而来的滑动门导航：DEMO演示







根据上面代码升级为滑动门样式



 Home
 News
 Store
 Group
 Community
 Help

其中，这两句有必要说明一下，以免被认为是多余的：

#navigation li a{overflow:hidden;} /* 隐藏掉IE5.5、6多掉的那3px，不是3px bug哈！因为height:30px;line-height:33px; 在IE5.5、6中高度就是33px了。 */ #navigation li a span{cursor:hand;}/* 照顾IE 5.5、6、7鼠标放在span上面不呈手型的bug。此外，IE5.5不支持cursor:pointer;但IE全版本都认识cursor:hand;*/

完工了，缺点就是，写那一行条件注释，对于有xhtml洁癖的人来说，就像眼里的沙子，想除掉，那就使用hack也无妨！呵呵！在safari4，chorme，opera10，ie5.5、5、6、7,ff3中均暂未发现问题。原文：http://www.blueidea.com/tech/web/2009/7281.asp

默认Web字体样式

RichieLiu — Thu, 17 Dec 2009 13:29:27 +0000

通常用户看到的页面的样式会受到三层控制，第一层是浏览器的默认样式，第二层是网页定义样式，第三层是用户自定义样式。和CSS一样，后面的优先级高于前面的，也就是说网页定义样式可以覆盖浏览器的默认样式，而用户自定义样式优先级最高。实际情况是虽然浏览器都或多或少提供了用户自定义样式的功能，但是极少数会有用户去自定义，一般用也是高级用户。而浏览器默认的样式往往在不同的浏览器、不同的语言版本甚至不同的系统版本都有不同的设置，这就导致如果直接利用默认样式的页面在各个浏览器下显示非常不一致，于是就有了类似YUI的reset之类用来尽量重写浏览器的默认设置保证各个浏览器样式一致性的做法。

拿字体来说，各个浏览器默认的字体种类、字体大小和字体行高都不一样，比如IE8的中文版在Windows XP下显示网页时默认字体是宋体，而英文版肯定不会如此。所以我们需要统一设置默认的字体样式，以便实现一致的显示效果来保证设计的一致性和提高开发效率。

以后准备使用如下默认字体样式：

body{
  font: 12px/1.5 arial;
}

字体：arial

我们页面的绝大部分内容字符都是中文，毫无疑问目前为止在网页上最常用也是最通用的显示中文的字体是宋体，但是宋体在显示英文、数字和英文符号时过于糟糕，比如©字符，所以我们一般期望通过CSS来实现用更好的字体样式来显示它们，然后用宋体来显示中文和中文符号。之所以选择arial是因为：

Windows和Mac都预装了这款字体，应该是使用最广泛的网页字体了。它的潜在对手tahoma和helvetica就没有这么幸运了。
视觉设计的专业人士可能会认为在Windows中使用tahoma、在Mac中使用helvetica更好，比如淘宝的默认字体样式是font: 12px/1 Tahoma, Helvetica, Arial, "\5b8b\4f53", sans-serif;这是一个很不错的选择，但是你也会发现Google、YAHOO、Youtube、Bing甚至MSN的新版都使用arial作为第一默认字体。所以从美观和可读性上来讲arial应该是完全可以接受的。
一般情况下设置font-family都会在最后设置通用字体族以保证其安全性，比如Google的设置为font-family:arial,sans-serif;，但是至少在非中文版的Win7下当编码是GBK时，IE8会因sans-serif来渲染宋体，导致字体出现变形，这就是为什么淘宝需要在sans-serif前加上宋体而Google无需这样做的原因。
因为中文字体的选择非常有限，所以目前所有的主流浏览器都设置使用宋体来显示中文。Baidu的首页和搜索结果页使用font-family:arial;可以从侧面说明这样做的安全性。可能有人注意到Firefox中国版默认显示的中文字体是微软雅黑，这是因为谋智网络擅自修改了用户自定义样式，不允许网页的样式覆盖浏览器设置的样式。也是由于类似的情况，我们要弹性设计网页非常重要。

使用英文字体作为第一默认字体会导致的问题之一就是中英文以及符号混排时的对齐问题、通过设置行高和hasLayout能解决绝大部分情况，但是都不会很完美，如果把字体改成“宋体”能彻底的解决问题。很明显，这个问题只出现在IE上。所以，如果你的网站很少使用英文、数字和英文符号，那么直接设置{font-family:\5b8b\4f53;}也是很合理的选择。

大小：12px

12px是宋体能显示的极限，虽然微软雅黑能显示更小的字体，但目前的应用环境尚未成熟。由于宋体基本上是目前显示中文唯一的通用Web字体，所以12px成为最常用的字体大小。我们当然可以依据产品的需要来修改这个默认值。
不用考虑基于字体大小（em）的设计。
在Chrome3.0之后的中文版中，字体大小最小值是12px，比如你设置最小字体为10px，最后也变成12px。

行高：1.5倍

这是一个经验值，不同的产品对这个值要求可能不同，但我们一般会设置最常用的为默认值。比如YUI的font中是font:13px/1.231 arial,helvetica,clean,sans-serif;即字体大小默认值是13px，行高是13*1.231=16.003px，默认的行高是默认字体的1.231倍。对于中文来说，常用的字体大小12px、14px、16px、18px等偶数大小，在IE6和IE7设置其行高也为偶数能解决一些特殊情况下的字体对其问题。
在IE6和IE7中，行高值必须大于字体的2px才能保证字体的完整显示或当其作为链接时能有效显示下划线。
设置line-height时，注意不要使用单位（包括%在内），因为子节点会继承经过运算后的line-height值，所以当使用单位后浏览器会把line-height计算成第一次定义的绝对值，而不会随着字体大小的变化而变化，而无单位的数值表示是所在容器的font-size的倍数，所以设置为无单位的数值是最佳选择。
深入CSS 行高非常有利于理解line-height，值得一读。

性能和效率

大部分平台都有arial，减少浏览器的查找时间。
代码最少，书写方便。arial基本上是名字最短的字体了，可以节约CSS的大小。
所有的字母都小写，目前Google就是这样做的，好处是既可以编写更快也能提升Gzip压缩的效率。
中文最好用unicode表示，比如使用宋体是{font-family:\5b8b\4f53;}，使用微软雅黑是{font-family:\5fae\8f6f\96c5\9ed1;}，这样的好处是避免编码问题，同时能得到所有的主流浏览器的支持。
使用正确的字体种类写法，避免使用引号，这样可以缩小CSS的大小。中文字体可以按上一条方式来编写。

未来

通过对中英文及符号混排的测试，我发现微软雅黑其实表现相当不错，包括英文数字和英文字符以及在IE6和IE7的显示效果上，但唯一的遗憾是在XP下如果安装了微软雅黑字体的用户没有打开“使用屏幕字体的边缘平滑”选项的话，在Firefox、Safari和Opera、特别是IE6下会非常模糊难以辨认。针对这个问题目前并没有很好的解决方案，所以只有等到IE6使用比率非常小的时候才可能正式的使用它。或许需要到2014年，XP死掉的时候。
虽然很早就有了@font-face，但是浏览器的支持、网速和商业问题，导致它很少被应用。最近关于字体的好消息是Firefox3.6将支持Web Open Font Forma。关于Web字体未来的相关信息可以看Web 字体的未来、关于 Web 字体：现状与未来和再谈 Web 字体的现状与未来。

最后推荐一下玉伯的《再谈 Web 默认字体》

原文：http://dancewithnet.com/2009/11/22/default-web-font-style/

垂直栅格与渐进式行距(下)

RichieLiu — Mon, 07 Dec 2009 13:25:07 +0000

新问题

来也匆匆，去也“冲冲”。距上次发布垂直栅格与渐进式行距(上)发布，已经不知不觉过去了两个多月了。反过来，看看上次的成果。诶？怎么感觉边注有点奇怪呢？

(demo-6.html)

还是参考我的这篇关于排版的文章：我们知道

中文互联网上最常用的行距是1.5左右
行长越长,需要的越大的行距. (行距太小,读者阅读换行时容易串行. 行距太大,读者阅读行时会感觉到文字不连续.)

看来，对于边注的12px字体大小的，24px的行高显然过大了。但是，根据上一篇文章的方法，垂直韵律需要边注的行距和正文的行距应当一致。那么为了保持垂直韵律，我们只能同时减少左右两边的行距——总结：不靠谱。那么，我们该如何调整边注行距，却又能够让我们建立的垂直韵律生效呢？这就需要我们引入渐进式行距。

渐进式行距

总得说来，渐进式行距是对死板的垂直韵律的一个补充。垂直韵律是要求边注和正文的每一行都对齐。相比之下，渐进式行距让边注和正文也对齐——但不是每一行——而是每几行对齐一次。一般是每4行或者每5行对齐一次。我们回顾一下上一篇文章，知道，本文开始的那张例子，“配置”如下：

正文：字体大小14px，行距24px，段后距24px
h1：字体大小24px，行距24px，段前距24px，段后距24px
h2：字体大小：18px，行距24px，段前距12px，段后距12px
边注正文：字体大小12px，行距24px，段后距24px
边注边框：边框粗1px，内补白11px——别忘了还要把它上移12px

我们修改边注的行距和段后距都为18px。那么情况就会像这样：

(demo-9.html)

不知道各位看官发现了没有，为什么第一行基线没对齐呢？这是因为流布局会将文字块按照行高做顶端对齐。如下图：

所以，在这里，为了使首行基线对齐，我们还要将边注下降一定的像素。可恨的是，需要下降的像素是多少——这个很复杂的问题，至少经过不才好几次的尝试都没有看出个规律来，而只得出以下三个结论：

设正文行高是h px，边注行高是h’ px，需要下降的值为d px，那么，这个值将介于 1/2(h-h’) < d < (h-h’) . ①
如果该行引入了西文字符(半角数字或者字母)，该行的基线有时会比没有西文字符偏移一个像素。
不同的字体渲染引擎可能行为不一致。

这个结论并不能有成型的公式来确定需要下降的具体像素值。那么，我们就根据结论①一个一个像素试验吧(3 < d < 6)，反正不会太多。在本例中经试验可得，下降4px是能够让首行对齐的。对齐后，各位可以看到正文每隔4行，边注每隔5行，他们的基线会对齐一次。

(demo-10.html)

很有趣，是吧？

垂直栅格与渐进式行距应用举例

这套理论看起来略显枯燥。所以，我还是得举个应用的例子，不然理论对于现在来说没有任何意义。前几天，我遇到了一个问题是这样的：有一个系统，它能够用像 iGoogle那样的模块迅速搭建一个页面用于淘宝的各个子页面。但是，用模块搭建却常常遇到开天窗的问题，就像下面这样：

再看看模块本身，文字基线均未对齐，行距七零八落：

好，现在，我们开始开刀。首先，我们用6px的红色网格线，画好标尺。为什么用6px呢？我们在前面的例子中，正文行距是24px，边注行距是18px，那么他们的最大公约数就是6px. 也就是说，如果我们画好以6px为单位的横线族，那么，每3条横线就是一个18px单位，每4条横线就是一个24px单位。

画上线后，工作简单啦！利用18px和24px这两种行距，将文字的基线都挪到红色网格线上。

去掉网格看看吧：

回顾一下优化前的样子：

全部使用了18px或者24px的行距。其中，将右边模块的资讯条数由8条缩减为5条。甚至，我们可以继续发现，应用了垂直韵律之后，垂直的行数可以做自由得调整，而两个模块的高度可以保持高度一致。例如我们缩减了行数：

应用了垂直韵律之后，既美观又灵活，何乐不为呢？哇咔咔～

最后

当然，垂直韵律和渐进式行距还有很多应用的方法。总之，作为设计师，特别是网页设计师/交互设计师，我们不应当单纯地凭借感觉，应当专注到像素级别，严谨设计。

“严谨”一词，永远受用。送给我和大家。

文章转自：taobaoUED

垂直栅格与渐进式行距(上)

RichieLiu — Mon, 07 Dec 2009 13:21:23 +0000

准备工作

去年的时候,青云发表过关于栅格系统的文章 . 我们知道网页的栅格系统是运用固定的格子设计版面布局,使其风格工整简洁. 视觉上来说,栅格系统能够将大块区域分割成小区域,清楚地展示页面的布局,并能够引导视觉线在各个板块之间扫描、阅读. 从信息上来说,栅格系统让信息的呈现方式更加直观,从而有效提高易读性.
但是大部分栅格系统是在水平方向上的布局,其实,我们的垂直方向也是有栅格系统的——也就是我们的“垂直韵律”.

垂直韵律的就像好比我们手上拿着的线格本子，有着一行行的网格线，安排着垂直方向上的文字排版。“排版中的空间就像是音乐里的节拍. ”音乐的节拍虽然有许多变化,但是几乎每首歌都会有一个固定的节拍来掌握整个歌曲的节奏. 这就是为什么栅格系统一般用固定宽度的网格阵列来指导和规范网页中的版面布局以及信息分布.
其实，那么,在网页里,垂直韵律应由三个因素控制：

字体大小(font-size)
行距(line-height)
具体定义可以参照我的《字体、排版简明入门》中行距这一节
间距(margin,padding)

认真考量这三个因素的值,才能实现垂直韵律.

开工

基础行距

在垂直韵律中,基本的单位是行距. 在整个页面上设定一个合适的行距是垂直韵律之所以能够成为韵律的必要条件. 这个行距,我们将应用于整个页面的所有文字上,包括正文、标题、侧边栏等. 例如,我们现在设定我们的字体大小(css font-size)为12px,行距(css line-height)为18px. (对于中文宋体来说,12px是能够清晰显示的最小字号. 为了保证可读性,12px的1.5倍行距就是18px. 同时12px/18px也是中文互联网上最常用的字号和行距. )我们在空白页面的垂直方向上以18px为单位做垂直网格,就像我们线格本子上的线条,每条网格线也就是基线的对齐线. 接着，我们放上三个段落(12px/18px)作为例子讲解.

(demo-1.html)

段落间距

段落间加上段间距不但美观,而且容易在视觉上区别各段落. 但是要注意的是,垂直韵律最容易被打破的地方就是两个元素在垂直方向上的空白了. 所以,为了让下一段的文字内容落在网格内,我们要将段落间距设置为基础的倍数. 例如：我们可以设置段前距为9px,段后距为9px,9px+9px=18px；或者设置段前距(css margin-top)为0,段后距(css margin-bottom)为18px；或者段前距和段后距都是18px. 这里,我们选取第二种方案,即,设置段前距为0,段后距为18px. 图中可以看到,每段段落的文字都落在了格子内. 关闭网格可以发现,段落清晰明了,比之前容易阅读多了.

(demo-2.html)

添加标题

使用浏览器默认的样式,你会发现,大多数情况下,垂直韵律都被打破了. 所以,添加标题,我们需要选择正确的行距和间距才可以.

有了添加段间距的经验,相信添加标题也不是一件难事了. 标题的文字要比正文的文字要大的多. 例如,我们现在选择h1的字体大小为24px.

那么,根据附录结论有：

行距和全部垂直间距之和为基础行距的倍数。

那么，我们假设行距为36px,则可以设置段前距为9px，段后距为9px (验证有：36 + 9 + 9 = 54 = 3 * 18).

同样，我们也可以设置h2:字体大小18px，行高24px，段前距3px，段后距9px(验证有：24 + 3 + 9 = 36 = 2 * 18)。

(demo-3.html)

添加边注

网站我们常常有侧边栏，我们这里就用右边的边注来代表。在这里的例子中，我们和正文一样设定边注的排版：字体12px，行距18px。正是由于我们前面的努力，我们可以看到，边注的基线和正文的基线是对齐的。关闭网格可以看到，由于基线的对齐，整个排版有条不紊，十分美观。

(demo-4.html)

添加边框

添加边框道理相同，无非要的就是最后要求基线与网格对齐。这里的例子中，我们来给边注加个边框吧。给他加上1px边框(css border)后，还要再加上8px的补白(css padding).细心的同学们一定发现了，为什么补白是8px呢？其实很简单，这就是保证垂直方向上的补白和边框之和，是我们的基础行高18px的倍数：垂直方向上两个补白两个边框，那么1 + 8 + 8 + 1 = 18.

加上去后，我们发现，恩？怎么没有右边文字没有对齐到网格上呢？原来加上了补白和边框后，边注下移了9px，所以网格就没有对齐啦。那么，我们就要把边注上移9px。现在，我们可以看到右边的文字已经对齐到网格。是不是感觉不错？

(demo-5.html)

不同字体大小的正文

如果有一天，老板告诉你，正文的字体太小啦，他看得眼花。你因此不得不将左边的正文设置成14px大小的字体，右边的边注保持12px。由于正文字体变大，我们也同时加大行距。根据我们前面学到的知识，我重新设计了间距：

正文：字体大小14px，行距24px，段后距24px
h1：字体大小24px，行距24px，段前距24px，段后距24px
h2：字体大小：18px，行距24px，段前距12px，段后距12px
边注正文：字体大小12px，行距24px，段后距24px
边注边框：边框粗1px，内补白11px——别忘了还要把它上移12px

效果见:

(demo-6.html)。

完工

OK，最后，我们来做个使用前使用后的对比，来张合照吧：

使用前：

使用后：

附录基本垂直韵律对行距、间距的要求的推导

根据之前的经验,不难得出：

设行距为 dl px ,设垂直方向上的间距和为 ∑ds = dst (段前距) + dsb (段后距) (px) ①,假设基础行距为k px,则

n*k = dl + ∑ds (n为自然数) 即行距和间距之和应当是基础行距的倍数 ②

由方程①、② 得出：

行距和全部垂直间距之和为基础行距的倍数。

文章转自：taobaoUED

网页栅格系统研究（4）：技术实现

RichieLiu — Mon, 07 Dec 2009 13:18:35 +0000

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

Blueprint的实现

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

以上三栏布局的代码为：

上面是基本功能，Blueprint还支持append-n, prepend-m, border等“高级”功能，这些就不细说了。Blueprint的特点简单总结如下：

采用浮动来实现布局，简单明了
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的，但我们只要将

中的id改为doc2, 页面宽度就自动变为950宽了（YUI非常强大^o^）。来看下dom结构：

采用的也是浮动布局，简化后的CSS代码为：

YUI的特点是：

依旧是采用浮动布局，槽（Gutter）宽通过margin-left来控制（Blueprint采用右边距，960.gs采用均分，这三个框架对槽的处理实在有意思）
总宽度采用em, 这样可以用在弹性布局上
栏的布局用的是百分比，采用了流体布局

YUI的好处是能用来做自适应布局，在这前面两个框架里是没有的。但普通的定宽布局，YUI则显得有点麻烦，比如我们要实现四栏布局，dom得这样写：

先来两个两栏布局，再细分为四栏布局，清晰度上欠佳。

双飞翼栅格系统

挺奇怪这个名字？请先阅读这篇文章：渐进增强式布局探讨. 简单说，双飞翼布局是一种布局实现技术，可以利用它来实现一整套栅格系统。

先看test页面：Grids Layout Test.

具体技术细节在渐进增强式布局探讨一文中已经阐述，这里不再重复。有几点需要说明：

这套栅格系统并不能实现所有布局。这和YUI Grids类似，只能实现预定的一些布局。比如三栏布局，目前只加入了5 : 13 : 6, 5 : 12 : 7, 9 : 9 : 6, 8 : 8 : 8四种情况，这是从淘宝的现有页面中分析总结出来的。对于同一个站点来说，太多不同的三栏比例不是好事（淘宝目前都有点多，以后可能还会进一步统一）。因此如果采用这套栅格系统的话，需要先分析站点，定义出一套合适的比例。这里有个所有比例的自动生成工具：grids_css_generator.html.
关于命名：.grid-c2-s6表示两栏（c2: column 2）布局，sub栏的宽度是4列（s4: sub width is 4 * 40 -10）. 而.grid-c2-s6f, 最后的f表示两栏布局的第二种情况，即sub和main互换。类似地，.grid-c3-s5e6d表示三栏布局，其中sub栏的宽度是5, extra栏的宽度是6, 最后的d表示是s5e6三栏布局中的第四种情况。
为了方便使用，将最常用的两栏布局.grid-c2-s5用.grid-c2直接表示。同样的，.grid-c3表示.grid-c3-s5e6. 这是淘宝的默认值，其他站点可以根据实际情况修改。
这套布局符合渐进增强式工作流程。细心的你可能已经发现，所有两栏布局和三栏布局，HTML中的DOM结构是完全一样的，只有最外层div的class不同。如果要交换左右栏，只要非常简单的修改下class就可以。
实际使用时，两栏布局和三栏布局已经够用。其实有了两栏，其它布局就都可以组合出来。这里有一个尝试性页面：grids_test4_v0.1.html. 组合布局看起来很强大，但实际使用时会把问题搞复杂，不推荐使用，干脆忘掉吧。

最后来看下两个测试页面：两栏布局grid-c2_test.html 和三栏布局grid-c3_test.html.

目前除了发现在ie6下有个bug（超大图片等会撑乱布局，其实可以用overflow: hidden来解决，但考虑overflow的负面影响，最后还是由布局内部的模块来自主控制的好），尚未发现其他问题。

小结

栅格系统更多的是一种布局思想，在实际使用时，根据具体需求选用合适的技术来实现即可。需要注意的是，对于栅格的技术实现来说，太灵活未必是件好事，适度灵活最难得。怎么才能适度呢？这需要疯狂实践 + 不断的反思 + 持续的重构 + 悟…

栅格搭好了页面框架，接下来很重要的一件事情就是往里面添加内容模块。让内容模块规范化，让页面生成工业化，对大型站点来说，这是栅格系统最有商业价值的地方。下一篇也是本系列最后一篇将展示栅格系统中的模块化应用。

文章转自：taobaoUED

网页栅格系统研究（3）：粒度问题

RichieLiu — Mon, 07 Dec 2009 13:07:34 +0000

研究（2）中讨论了栅格系统的基础知识。这一篇将集中探讨栅格系统的粒度问题。（注：如非特别指明，栅格系统均指24列960栅格系统）

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

（图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中的例子，暗合栅格往往能简化布局上的考虑

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

文章转自：taobaoUED

网页栅格系统研究（2）：蛋糕的切法

RichieLiu — Mon, 07 Dec 2009 13:05:21 +0000

首先澄清一个应用场景问题。研究（1）中指出，对于结构复杂的网站，不少设计师们喜欢采用960固定宽度布局。但要注意的是，960并不是万能钥匙，大部分网站没有也不需要栅格系统。Amazon采用的是宽度自适应布局，最大限度的呈现信息。Google更是简简单单，主题部分就一个列表。eBay的页面非常简洁，商品页面宽度自适应，信息自然流畅，噪音少，购物很踏实。类似的站点还有很多，对于这些站点来说，宽度自适应布局更受青睐。

有个很有意思的网站是Yahoo!, 看起来是固定宽度布局，实际上在CSS中只要去掉一行，就能摇身一变自适应宽度了：

#page {
    width: 70em;
}

为什么Yahoo!最后选择了定宽布局呢？这很可能是因为定宽布局比宽度自适应布局更容易控制。对于结构复杂的网站来说，可维护性和可扩展性非常重要。Yahoo!是以信息展示为主的门户型网站，960的宽度对于信息的阅读比较友善（Joe Clark写了一篇屏幕阅读时有关行长的有趣文章）。种种因素使得Yahoo!最后采用了定宽布局（Tommy Olsson总结了每种布局设计的优缺点）。

这里将只关注定宽布局，适用的场景是搭建复杂的门户型网站。对于宽度自适应布局和相应的栅格系统，暂不讨论（根据实现的技术手段不同，宽度自适应布局又分为流体布局和弹性布局。我个人蛮喜欢弹性布局，以后有时间再研究）。

好了，已经将范围缩小到定宽布局的网页栅格系统，那我们开始吧。

并不遥远的750

还记得800×600的显示器不？虽然才时隔几年，感觉却好像是上个世纪的事了。Mark Boulton做了最早的探索：

将750分割成均等的6份，这就形成了栅格系统，稍加组合划分就形成了两栏布局和三栏布局。Mark Boulton还研究了Gutter（垂直栏之间的间隙）对栅格的影响，有兴趣的可以阅读原文，或者跟着我往下看吧，下面将详细阐述。

几个术语和一个公式

一个标准的栅格系统，包括以下部分：

将Flowline的总宽度标记为W, Column的宽度标记为c, Gutter宽度标记为g, Margin的宽度标记为m, Column的个数标记为N, 我们可以得到以下公式：

W = c * N + g * (N - 1) + 2 * m

一般来说，Gutter的宽度是Margin的两倍，上面的公式可以简化为：

W = c * N + g * (N - 1) + g = (c + g) * N

将c+g标记为C, 公式变得非常简单：

W = C * N

上面的公式就是栅格系统的基础，很简单吧。

950的来历

具体应用时，Margin其实是一个空白边，从视觉上看并不属于总宽度。不少栅格设计里习惯性地设定Gutter为10px, 这样Margin就是5px. 当W为960，分割成6列时，栅格如下图：

上图的处理是左右Margin各为5px. 也可以将Margin集中放在一边，比如右边：

无论Margin放在何处（这只影响技术实现，不影响设计），我们真正要关注的是去除Margin之后的部分：

这就是我们要真正关注的950！将W的含义变为去除Margin的总宽度，公式变化为：

W = N * C - g

将上面的公式实例化一下：

950 = 12 * 80 - 10
950 = 16 * 60 - 10
950 = 24 * 40 - 10

这就形成了960蛋糕的三种常见切法。

12 x 80

16 x 60

24 x 40

上面三种切法，N越大，灵活度越高。可以根据网页的实际复杂度来选用对应的切法。在960 Grid System首页中，展示了12 x 80的应用：

我们来看下研究（1）中开头列举的网站的栅格应用情况。

Yahoo!是很标准的 24 x 40 栅格：

淘宝网目前只有商城上部分使用了栅格系统（大的两栏布局遵守了 24 x 40 的栅格化，主体部分使用的另一套740的栅格划分）：

网易很不错，采用的是 16 x 60 的栅格系统：

研究（1）中的其它站点都没有真正严格地采用栅格系统。

栅格系统的优势

上面的“发现”是让人有点沮丧的。目前严格采用栅格系统的站点非常少，为什么我们还要努力的让网页栅格化呢？

栅格系统具有以下优势：

能大大提高网页的规范性。在栅格系统下，页面中所有组件的尺寸都是有规律的。这对于大型网站的开发和维护来说，能节约不少成本。
基于栅格进行设计，可以让整个网站各个页面的布局保持一致。这能增加页面的相似度，提升用户体验。
对于设计师们来说，灵活地运用栅格系统，能做出很多优秀和独特的设计。（详见《超越CSS》一书）

对于大型网站来说，我相信栅格化将是一种潮流和趋势。

下面讨论栅格系统中的黄金分割。

黄金分割

黄金分割可以归结为数学问题：对于长度为1的线段，将其分成两部分 x 和 1 – x, 使得：

x / 1 = (1 - x) / x

化为简单的二次方程：

x^2 + x - 1 = 0

正数解为：

x = (sqrt(5) - 1) / 2 ~= 0.618

这就是黄金分割。这个比例不仅仅出现在诸如绘画、雕塑、音乐、建筑等艺术领域，在管理、工程设计等方面也有着不可忽视的作用。（这是个自然界的魔数，类似的还有真空光速、普朗克常数、精细结构等等，感兴趣的Google吧）

在平面设计领域，黄金分割点被广泛采用。比如下面这种图：

数一数上面有多少黄金分割？

对于960栅格，实际宽度是950. 两栏布局时，黄金分割为：

对于 24 x 40 的情景，最接近黄金分割的两栏布局是 350 : 590, 栏数比例为 9 : 15. 但实际使用时，因为窄栏经常用来做导航或放辅助信息，并不需要350px这么宽。因此实际情况下经常被采用的布局是：

上面讲的都是宽度方向上的栅格化，下面我们看看高度方向上如何应用。

高度方向上的栅格

还记得研究（1）中那张红红的很刺眼的图吗？注意高度值560也是很神奇的。

N(560) = N(2^4 * 5 * 7) = 18
560 / 960 ~= 0.583

N(560)比较大，同时可以让高宽比接近黄金分割。针对560, 我们采用 14 x 40 栅格：

这样，我们就在宽度和高度两个方向上都实现了栅格化。

下一篇将详细阐述960栅格系统的模块化应用。

文章转自：taobaoUED

由黄钻等级图标处理引发的思考

RichieLiu — Thu, 19 Nov 2009 12:58:34 +0000

最近在处理Qzone黄钻图标更新时，想起近期对业务图标进行优化所遇到的一些问题，把思绪收拾起来和大家一共探讨，欢迎多方声音。

在实际工作中，图标类的应用非常广泛，如同数组般的等级图标更显其特殊性。下面要共同探讨的两个方向，以什么方式实现及怎么更好在贴近项目实际更好地实现并供应用。

假设：业务的用户等级共有10个，加上大小2种视觉尺寸的图标，还有“过期未续费用户”的表现，共有38个图标需要入库供调用（如下图）。

在项目的CSS框架研发中，会有几个key作为考虑：请求数、代码量、兼容性、图片文件大小、是否可并为组件模块且方便逻辑性实现。

众多不同等级的图标在不同方式的广泛应用时，是否会产生过多的文件请求；
等级图标的代码在实现上是否会使用过多的代码，且页面上真实应用的只是少量代码，从而造成代码臃肿；
(x)html+css输出的图标应用到页面中，是否和页面上其它元素兼容，否则将为达到兼容目标而增加一系列代码；
如果各图标合并后，权衡项目应用的实际情况，图象文件是否会过大而消耗带宽；
图标的HTML固定，className命名中的某个数字命为作为变量，通过修改变量来达到表现效果。

回顾之前的出现的处理方式，可以归总为三种：

前景图的插入
这应是最原始的处理方式了，将众多单个等级的图片有序命名存放到一个目录，由前端页面应用，通过修改文件名的方式更换不同的等级显示。在实际的用户列表页面中，因为不同的用户通属不同的等级，那么，就会显示不贩等级图标，如上面假设，就会同时产生38个请求。且在项目的维护上，极易存在瓶颈。假设根据需目需要对图标文件更换存放目录或更改其尺寸大小，那么需要大面积对所有应用过的开发 template文件排查处理（更改URL，宽高定义，文件名等），很多情况难以维系在可控范围。
透明图+背景的实现
这是Qzone项目中使用最多的一种方式，在项目的访问速度体验优化及图标实际应用中起到不可磨灭的作用，该方式后期也陆续为国内外其它网站使用。其具体实现方式是，保存一张1*1像素的透明图片，并将其设置长时间cache，因其display属性的特殊性，图片在页面布局上得心应手，且解决了多请求的问题，同时解决图片合并区域扩展维护的问题。但是，一旦在客户端cache文件队列中被挤掉，cache失败，该方式容易让这张透明的前景替位图产生洪水式的请求，造成服务器压力和大流量。且容易继承项目中其它定义。在图标与文字的垂直对齐上各浏览器的渲染解析不一样，从而增加一些兼容代码。
也有衍生出来空src的处理方式，如，表面上看，可以节省文件的请求，但事实上，它除了会导致大量的无效请求外，还会向日给apache不断写入错误的log，造成过大的服务端压力，同时，在非IE浏览器（如firefox)也会表现出缺省图象的红叉。
内容标签+背景
这里说的是带文字等内容的标签加入黄钻等级图标背景来实现，如我是黄钻7级用户，给span的左边定义一个图标，把文字向右移动一定的位置。大伙在实践中验证，这种在语义上和实现上，可以说是完美的了。但是，不方便项目代码的规划和管理，特别像等级图片这类的可以归入库的代码及应用方式。同时，标题的大小区域为不可控，在后续的维护中，更会不定期更改其区域大小，那么，就在图片的合并上存在瓶颈，难以确定一个图片该预留多大的透明区域，使之不影响到其它场景的图片应用，也可能会因为后期的维护处理不当，影响到其它标签区域的背景显示异常，造成不良的用户体验。
标签载体+背景
结合前几点所述，用一个标签作为图片的载体，再给它定义背景等属性，显示出相应的图标。它既可以免除用图片处理产生的流量和请求及服务器压力，又减去合并图片时所考虑的预留空间尺寸。一般标签不具img的特殊属性，既能成块状显示出图标，又能和文字等共处一行内，那么在选取的这个标签要在样式上定义得较少，不易继承样式影响表现，破坏页面的兼容和库文件的管理维护。
在实际项目中，选用了strong作为图标的替代标签：

回顾完各种处理方式后，一起来了解一下实现上的细节，分析一下文章第一张图所示，共有38个图标，且都是图形化，原始想法是，把38个图合并成一个文件。但细心看，这38个图片，有好多的相同的图形，经过整理后，得到下面这张图：

除四个图标载体外，数字都是相同的，因为这里使用的是第四种处理方式，那么在图标的合并上，不用给各小图片块预留过多的透明区域。
雪碧图处理好以后，就可以着手写代码来实现效果了。

lv1
lv2

为了让标签具有img的特有属性，给strong定义display:-moz-inline-stack;display:inline-block;
因各浏览器兼容性的原因，需要定义了两个属性，这里不禁一定要问了，为什么不选用-moz-inline-box呢？这里选用-moz-inline-stack而非-moz-inline-box的原因是：

使用-moz-inline-stack可以解决Firefox2不支持inline-block的问题，但是所有的Firefox版本对于属性为-moz-inline-stack的Element，它的First child element会继承该Element的宽度和高度，但是再下一级的Element不会再继承该属性。
这里说说一下与本图标应用无关的话题，在实际应用中-moz-inline-box会存在元素间的对齐等问题，在处理自适应宽的

设置完display属性后，我们就给图标定义宽高。实际的图标处理中，完成这两步基本就OK了。但是这个图标应用较为特殊，因为它是两个背景合成一个图标的（载体+等级数），如下图：

下面是两个载体的拼合示意：

所以在结构上加多了两个span，一个是给等级数字的背景载体，另一个是隐藏图标替换文字。

代码写完后，发现代码量相当的惊人，因为只在最外层定义不同的className，那么，就意味着，我们要对众多个类及其里面的标题定义：
.gb_vip_1 span, .gb_vip_2 span, .gb_vip_3 span, .gb_vip_4 span, .gb_vip_5 span, .gb_vip_6 span, .gb_vip_7 span
这样代码就相当臃肿，于是，改变className的定义方式，给各个等级图标最外层容器定义相同的命名，给里面数字的载体定义区别显示的命名(带数字的命名是方便逻辑实现)：
lv1 lv2
以上所述的供讨论和参考，期盼大伙一些其它的想法和分享。

原文：http://webteam.tencent.com/?p=1330

刘钢的博客 - 我是UED » 页面实现

[转]让Web开发者事半功倍的8个网站

再谈float菜单局中

默认Web字体样式

字体：arial

大小：12px

行高：1.5倍

性能和效率

未来

垂直栅格与渐进式行距(下)

新问题

渐进式行距

垂直栅格与渐进式行距应用举例

最后

垂直栅格与渐进式行距(上)

准备工作

开工

基础行距

段落间距

添加标题

添加边注

添加边框

不同字体大小的正文

完工

附录 基本垂直韵律对行距、间距的要求的推导

网页栅格系统研究（4）：技术实现

Blueprint的实现

960.gs的实现

YUI的实现

更多栅格实现

双飞翼栅格系统

小结

网页栅格系统研究（3）：粒度问题

纷乱的高度世界

一切皆有可能

然而，现实总那么残酷

宽度世界里会好些吗

银弹是不存在的

网页栅格系统研究（2）：蛋糕的切法

并不遥远的750

几个术语和一个公式

950的来历

栅格系统的优势

黄金分割

高度方向上的栅格

由黄钻等级图标处理引发的思考

附录基本垂直韵律对行距、间距的要求的推导