1. 在中英文混排的情况下，对于IE6的行高bug，推荐还是先统一为中文字体（宋体或者雅黑），再使用 vertical-align: middle; 可以减少时间上的浪费。

2. IE6一个已知的BUG：当某position:relative元素被带有overflow:auto/scroll 属性的块级元素包含时，会表现出postion:absolute 的行为。 解决方法： 1.为包含块元素添加属性 position:relative 。2.把该元素的position:relative属性去掉，使用默认的 static 定位，并通过 margin 等属性实现类似的效果。

3. IE6的z-index bug，可在需要浮在上方的元素中添加 iframe 且设置为同等宽高 z-index 位于其下，则可借助IE6“将iframe浮于所有元素之上”解决：这是个贱方法，没事儿千万别用。

4. IE6重复内容bug：一个元素包含2两个具有 float 样式的子元素；第二个子元素的宽度大于父元素的宽度，或者父元素宽度减去第二个子元素宽度的值小于3px；第二个子元素前存在注释。如果满足以上条件，第二个子元素中的内容会部分重复出现。

5. IE6中，DOCTYPE 之前有任何非空字符都会触发怪异模式；在IE7下，DOCTYPE 之前有XML文档声明不触发，但在 DOCTYPE 和XML文档声明之间有任何非空字符仍然会触发怪异模式。

6. 对于IE6把 height 当作 min-height 的状况，overflow: hidden 有时真是一剂救命良方。

7. 对于块级元素与行内级元素，除了盒模型在纵向上的差异，布局上的影响也值得留意——行内级元素在拥有position、float属性之后会表现出部分块级元素的属性。

8. 在写完 float + margin 的配合之后，顺手在IE6样式中带一句display: inline;可以省却很多日后不必要的麻烦

对待超出容器范围的元素，一般常见的有两种解决方法：一种是添加滚动条（给容器添加overflow: auto），另一种就是隐藏元素超出范围的部分（给容器添加overflow: hidden）。虽然从可用性角度应该使用添加滚动条的方法以保证客户可以获得所需信息，但是在很多时候用隐藏的方法比较不会引起页面整体感觉混乱。不幸，世界上目前市场份额最大的浏览器——IE6——对于overflow: hidden的支持不佳。如果单单是给容器添加overflow: hidden很可能根本看不见任何效果。但是一旦容器有了固定的高度、宽度，overflow: hidden立刻就达到了期望的效果。

IE6由于其东家——微软——的市场份额巨大加之长达5年的没有更新，可能是目前市面上 bug 所知最多的浏览器。IE 有一个概念叫做“拥有布局”（hasLayout，如果装了 IE Developer Toolbar 可以在属性栏看到），“拥有布局”某种程度上可以理解为就是拥有固定宽高。有不少 IE6 的bug仅通过给元素添加固定宽高就可以解决，这个就是跟 IE 的“拥有布局”概念紧密相连的。似乎很多时候 IE 都认为只有“拥有布局”的元素才可以拥有别的一些属性，因此有些时候，IE6 明明支持的CSS属性非要等到“拥有”了“布局”才会正常工作。说起来这也不是很难解决的问题，但是动辄要添加固定宽高会无端增加不比较的限制。由于目前还没有更加的解决方案——你能保证你的客户都是用 Fx、Safari、Opera 吗——因此，只能将就一下，think like IE.

折腾了近半个月现在的blog皮肤——目前代号“eros”——没有任何进展。庞大的背景花纹载入过慢问题我头疼了很久，最后也没有找到更好的解决方法。原先基于 eros 样式开发的新 gallery 倒是引出了风凝进军AJAX的新热情。或许我本身也不擅长架构三栏的blog，总是弄得 sidebar 信息过剩强了正文的风头。近来也厌倦了顶头一条下面几列的模式，打算挑战一下以前没有尝试过的风格。

或许我就是一个慢热的人，某个灵感闪过，然后过上个把星期，才能把已经不知道飘到了哪里的灵感揪回来为我所用。目前的首页本身是一个很意外的收获，而直到前天，我才真正开始计划将这个意外收获好好利用。经过3天的折腾，最终有了现在的页面——Underbrush——

很朴素的页面，几乎朴素到了2002年的页面风格。纯粹的两栏结构，看起来几乎将所有的经历都花在了头部图片的设计上——实际上花时间最多的是色彩的选择和搭配，以及类似列表风格之类不太显眼的部分。某个瞬间我都要觉得自己的品味太老土了……

我想我不会半路放弃这个设计，并且会尽量在这个周末完成相应的 wordpress theme。除非在制作 wordpress theme 途中突然觉得令人作呕，我想我还是会坚持下来的。

到北京以后的第二个星期重新温习了《The Zen of CSS Design》，加上最近接触的公司的项目和刚刚完成的 training project，对于 margin、padding 外加浮动布局这几位老朋友运用得更加娴熟，同时也比以前有了更深的认识。

之前我一直觉得为了避免IE对于盒模型的非标准理解应该尽量使用 margin，但是最近发现这种想法有点天真——首先，margin 纵向叠加的问题是所有浏览器都存在的；其次由于IE对于“拥有布局”的奇特定义，几乎所有的著名 IE bug ——双空白边浮动 bug、3像素文本偏移bug等等——都是跟浮动布局和 margin 过不去。因此web标准组织目前推荐是尽量使用padding，尤其是在浮动布局的时候。如果非要在浮动布局的时候使用 margin，还是事先就准备好解决方法的好。

相对于在一个 css 文件中使用大量 hacks for IE，现在的我更倾向于为IE的各个版本浏览器分别编写样式表——这样一来，在代码的修改和维护方面会更加方便，至少不用去眼花缭乱的找下划线 hack 或者花里胡哨的 Tantek 框模型 hack 了。风凝在刚刚完成的 training project 中便分别编写了针对现代浏览器、IE 7 和 IE 6 三个样式表。在分别处理针对 IE7 和IE6 的样式表的过程中，确实能感觉到对于这些浏览器对样式表的呈现方式有了全新的认识。以前在写一些 hack 的时候总会有误打误撞的感觉，这次却觉得自己在完好的理解了W3C标准之外，又可以很好的转换为 IE7 和 IE6 的理解模式，如此一来，思路更加连贯，编写起来也更加得心应手。

其实现在想想，padding 还是比较好的——关于它的 IE bug 只有盒模型一项，处理起来又十分简单。当年我居然会排斥 padding，真是鼠目寸光了一把。在这次的 training project 中需要做出三栏流体布局。感谢 padding，没有让我遇到很多麻烦，只是很少的一点加减法就解决了IE6中的显示问题——不得不说一下，这次的 project 风凝真的是一直都没离开 Windows 自带的计算器，只是不知道是该感谢微软的贴心设计还是对自己日益退化的心算能力脸红。

从目前的形势来看，只要微软帝国不倒，只要页面还需要流体布局（浮动布局），padding 总还是要比 margin 让人放心。其实说起来，float 真的比想象中要好用，除了需要对浮动元素进行清理，真的已经是很完美的控制了；而且经常可以将浮动的各个部分想象成漂浮在方形木盆里面的木块，木块之间的漂浮原则完全适用于浮动布局，比如假设两个相邻的浮动部分宽度总和大于它们的容器宽度，就会有一部分浮动到另一个下面——两块在木盆里的木块如果宽度之和大于盆子的时候，自然会有一块模板漂在另一个下面啊。有时候形象思维就是有助于思考，hiahia。

关于 margin 和 padding 以及跟他们有关的一切一切事情，我越来越不敢自称精通。停留于“知道自己不知道”的境界，期待着“不知道自己知道”的来临。关于这些没完没了的琐碎东东，不知道我能发现多少乐趣。

似乎不少初学 CSS 的人对定位问题都很感冒，尤其是 margin、padding，简直能要人老命（秋香？！）。不过风凝在当初学的时候并没有遇到太大阻力。这还是要归功于当初小打小闹画过一段时间漫画，为了投稿不得不学习了“边界”（margin）和“补白”（padding）的概念。

所谓”补白“，就是为了防止在印刷剪裁的时候造成白边而填充的内容——也有人往里面画搞笑四格的。一般的漫画杂志会要求将画面内容画满补白，但是不能在补白中画上重要的部分——有点像《名侦探柯南》动画组在自行制作一集动画的时候不能涉及主线和人物性格（笑）。而”边框“，一般就是一片空白——这里是不允许画上东西的，但是也不可或缺，在页面与内容之间保持一定距离避免过份拥挤。至于那个”边线“（border），就是边框与补白之间的一条蓝铅笔线——通常蓝铅笔线是不会被印刷出来的，所以会推荐使用蓝铅笔画边线。

其实 HTML 诞生之处就是为了给学术论文排版，因此只要稍加留意就会发觉 HTML 和 CSS 中的很多东西就是印刷术语。在 CSS 里看似抽象的 margin、padding，在印刷上其实是一个很简单的概念。嗯…不知道做平面的设计师对于 HTML 和 CSS 会不会比常人更敏锐，或许更敏锐的是排版工人吧

其实说来说去看来看去也不如自己动手写几行代码体会深刻——随便找一段文字或者一张图片，在它的选择器属性中设定宽度、背景图片/颜色、边框、padding、margin，来回复制粘贴几遍文字/图片的 HTML 代码，然后把东西拿到浏览器里面去看就一目了然了——元素和 padding 都是有背景的，而 margin 则是将文字/图片和其他的距离拉远。

效果怎么样？

如果你是个好孩子，应该会大叫一声：Oh no!

如果你真的测试了，你就会发现一些怪异的地方——纵向的 margin 重合了！这个现象当纵向相邻的元素 margin 值一样的时候尤为明显，似乎我们就只设定了顶部或者底部的 margin。纵向 margin 哪里去了？

Margin 和 padding 折磨人不仅仅是它们的定义不好掌握，也在于它们真的有点捉摸不定——有一个名词叫做“压缩边界”，就是说纵向相邻的边界压缩。这样有好处，那就是当我们需要编排一个纵向无序列表的时候，我们只需要写下

li { margin: 5px 0;}

就可以得到间距都是5像素的无序列表。压缩边界的坏处就如我上面提到的那个例子——当我们需要在 padding、边框以外再留出一段距离的时候该怎么办呢？

答：在相邻的元素的 margin 上动手脚吧。

上面这句话不是忽悠，是实打实的解决方案。只有这样才能保证出来的效果和你的预期以致——要知道，有时候捷径并非直线的那条路。不过还是有一个好消息的——压缩只应用于 margin，padding 和 border 不会被压缩。

目前流行的浏览器对于 margin、padding 的理解各有不同——现代浏览器们，比如 Firefox、Opera、Safari、IE7，都是按照web标准解释的，那就是元素框宽度=margin+border+padding+ width；而IE6及其更低版本，却将width理解为元素宽度+padding，既元素框宽度=margin+border+width——所以我经常怀疑IE6及其更低版本的开发者以前是给漫画社供稿的。因此在浏览器兼容性问题中，遇到最频繁的问题是 width/height 的问题。遇到这种bug，下划线 hack 和 !IMPORTANT hack 是最简便易行的解决方法。

Margin 和 padding 之所以重要，是因为它们承担了定位的任务——web标准不提倡 table 排版而是大力提倡使用CSS，margin 和 padding 就是使得排版变得轻松并且兼顾了浏览器兼容问题的解决方案。试想如果没有 margin 和 padding，恐怕我们还要和表格定位的网页作斗争吧？

Sea Flower 给人借去了，所以抽点时间做个新的首页。

最近一直在看JavaScript的教程，但是进步很慢。羡慕人家页面上竖着放的一排小标签做导航很久了，但是因为技术不到家，不会用JS脚本生成，只好用CSS来达到相同视觉效果。唉……不知道什么时候能真正不必再眼馋人家的东西……

那排竖着放置的小标签使用了图片替换技术——添加一个空白的 span 标签，然后通过 position 定位覆盖住下面的文字链接。HTML代码如下——

• Home
• Blog
• Gallery
• KDr2
• About

貌似我所有的导航标签的HTML部分都长这个样子……不过想想也对，CSS才是控制视觉效果的部分么，哦呵呵呵……下面是相应的CSS——

ul#nav {
position: relative;
top: 0;
left: -29px;
float: left;
}
#nav li {
display: block;
width: 24px;
height: 50px;
margin: 5px 0;
position: relative;
overflow: hidden;
}
#home a span {
background: url(“../images/home.gif”) no-repeat;
position: absolute;
width: 100%;
height: 100%;
}
#blog a span {
background: url(“../images/blog.gif”) no-repeat;
position: absolute;
width: 100%;
height: 100%;
}
#gallery a span {
background: url(“../images/gallery.gif”) no-repeat;
position: absolute;
width: 100%;
height: 100%;
}
#KDr2 a span {
background: url(“../images/KDr2.gif”) no-repeat;
position: absolute;
width: 100%;
height: 100%;
}
#about a span {
background: url(“../images/about.gif”) no-repeat;
position: absolute;
width: 100%;
height: 100%;
}
#home a:hover span, #blog a:hover span, #gallery a:hover span, #KDr2 a:hover span, #about a:hover span {
background-position: -24px 0;
}

小标签们的背景图都是这个样子，

这样做的好处是可以减少不必要的加载时间，鼠标移动到标签上的时候不会出现闪烁。

这样做当然是有点麻烦，但是从可用性角度去讲，这样可以使无法加载CSS或者图片的人也能没有任何障碍的访问网页。不信的可以去掉页面的CSS看看，一样知道我要表达的东西是什么。

至于为什么要叫这次的首页为 Opera，不是要给那个浏览器做广告。只是前阵子听Vitas的 Opera #2 次数比较多，很喜欢，于是就借用一下咯……

另外，5月了，毕业设计到了要冲刺的时候，可能很长时间都不会更换首页和blog皮肤。有好的想法的话，我愿意把它们都藏在心里，而不是跟毕业设计争时间……

其实一开始是打算做成 Firefox only 的页面，好看看 IE6 下面究竟可以错位到何种地步，中午的时候看了一下 Google Analytics，IE 的访问量近乎一半……唉，没办法，只好放弃这个想法，认认真真做起了 IE hack。

IE6 中的 Carbonite 真是不看不知道一看吓一跳，错位得任务栏都认不出来了。自己搞了一个小时，不知道问题出在哪里。郁闷中打算听 Chris 的去 blueidea 发贴问问，谁知道 blueidea 的发贴方式实在是有够啰嗦，写了两行我写不下去了——还不如自己搞快呢。很幸运，找到了 13 styles，利用了一下人家的导航栏的代码，终于搞定了这个问题。

把两段代码都贴出来好了，以勉自己后来表再犯——

这个是(X)HTML部分——

• (miss)understood
• Gallery
• Archives
• Links
• About
• RSS

Firefox only

/*Credits: Dynamic Drive CSS Library */
/*URL: http://www.dynamicdrive.com/style/ */

ul#rootMenuItem{
float: left;
font-size: 14px;
line-height: normal;
list-style-type: none;
margin-left: 5px; /*Left offset of entire tab menu relative to page*/
}
#rootMenuItem li{
display: inline;
}
#rootMenuItem a{
float: left;
background: url(../images/root_menu_item_left.jpg) no-repeat left top;
margin-right: 5px; /*spacing between each tab*/
padding:0 0 0 6px;
text-decoration:none;
}
#rootMenuItem a span{
float: left;
display: block;
background: url(../images/root_menu_item_right.jpg) no-repeat right top;
height: 16px;
padding: 4px 9px 2px 3px;
font-weight: bold;
color: #000;
}

/* Commented Backslash Hack hides rule from IE5-Mac \*/
#rootMenuItem a span {float: none;}
/* End IE5-Mac hack */

#rootMenuItem a:hover span {
color: #FFF;
}
#rootMenuItem .current a{ /*Selected Tab style*/
background-position: 0 -22px; /*Shift background image up to start of 2nd tab image*/
}
#rootMenuItem .current a span{ /*Selected Tab style*/
background-position: 100% -22px; /*Shift background image up to start of 2nd tab image*/
color: #FFF;
}
#rootMenuItem a:hover{ /*onMouseover style*/
background-position:0% -22px; /*Shift background image up to start of 2nd tab image*/
}
#rootMenuItem a:hover span{ /*onMouseover style*/
background-position:100% -22px; /*Shift background image up to start of 2nd tab image*/
}

IE fixed

ul#rootMenuItem {
float: left;
font-size: 14px;
line-height: normal;
list-style-type: none;
margin-left: 7px; /*Left offset of entire tab menu relative to page*/
}
#rootMenuItem li {
display: block;
float: left;
margin: 0 1px;
}
#rootMenuItem li a {
display: block;
float: left;
color: #000;
text-decoration: none;
padding: 0 0 0 6px;
height: 22px;
line-height: 195%;
}
#rootMenuItem li a span {
padding: 0px 9px 0px 3px;
font-weight: bold;
}
#rootMenuItem li a:hover, #rootMenuItem li a.current {
color:#fff;
background: url(../images/root_menu_item_left.jpg) no-repeat left top;
}
#rootMenuItem li a:hover span, #rootMenuItem li a.current span {
display:block;
width:auto;
background: url(../images/root_menu_item_right.jpg) no-repeat right top;
}

教训——

1. overflow不是可以乱用的；
2. height+padding+margin 不是万能的——尤其对于IE6；
3. 代码少有时候就是好。

首先，我承认这个标题有剽窃某知名站点之大号的嫌疑，不过对于现在的网页制作来说，却是一句大实话。不管是以前用 table 还是现在用 DIV+CSS，搞不定定位，基本上就是空谈。

关于定位，前提是要有一个良好的CSS书写习惯。看了不少别人的代码和一些教程之后自己也有了不少的领悟。最基本的，我觉得对于那种唯一的或者是整体布局方面的div用id比用class要好，因为id是一次性的，且比较醒目，而class可以反复使用，适合作为文字排版等重复劳动。

昨天突然灵感乍现，做了现在的首页——源代码随便观赏，只是可能有些过短，对于部分人来说可能会有些刺眼。在定位问题上，我用了从《CSS Mastery》启发来的小技巧——将用作基准的图片（我的首页里就是中间的那个名片）放进某#字头类的background里面，然后写上

position: relative;

接着再将相对于基准定位的图片（首页名片右边的小标签）放入另一个#字头类的background，写上

position: absolute;

然后记得在写 HTML 的时候将后一个嵌套进前一个里面，这样后一个图片就会相对于前一个图片的位置进行绝对定位了。我折腾了不到一个下午，结果如下

在Fx、IE6、IE7里面测试都合格，几乎是一次成功。

定位除了基本的居中对齐、浮动对齐，其实对于一些需要特别效果的页面，position 的效果会出其不意——因为position 相对/绝对定位的图片上与其他元素没有其他瓜葛，做部分修改的时候可以不会对整体布局伤筋动骨，是居家旅行、杀人灭口，常备良药。

看过了 CSS Mastery 才知道，所谓的“Fx浏览网页问题”其实是IE自身的问题。想那 IE 6 少说有5、6年没有更新，早就属于老掉牙的浏览器了——石器时代的网景我们就不讨论了；相比之下，Firefox 和 Safari 几乎是个把月就要更新一次，一旦发现bug立刻就会出补救版本，且也算是比较严格的遵守了W3C的规则。而IE作为的M$的产品，很自觉的继承了M$一贯的妄尊自大，偏就是喜欢按照自己的标准来，不鸟W3C那一套，加入了一大堆非标准的插件，才会有了所谓的“很强的兼容性”，打倒了不思进取的网景。由于windows的横行，IE也是占了绝对市场份额的主流浏览器，许多上网的人都是用IE浏览器，许多制作网页的人也都是从照顾IE起步。这就有了一个很大的问题：按照标准教程去学 XHTML+CSS 会发现书本上讲的东西在IE浏览器中许多地方都不对，为了照顾市场以及自己的饭碗又要学习一大堆hack手段，使得hack被滥用而真正的标准又被无视。更有甚者，干脆就奉IE标准为圭臬，大骂 Fx 和 Safari 兼容性烂。这种本末倒置的事情，满坑满谷。

很幸运的，从04年中开始我便一直把Fx作为主要使用的浏览器——所以到了Ubuntu，也没有什么不适应的地方。所以现在 XHTML+CSS 的时候，都是先用 Eclipse+Fx 把骨骼都搞定，然后再放到IE里面去看效果，在不伤到基本骨骼的情况下进行调整或者使用一点hack手段，兼顾一下广大 IE 6 用户。

因为机器配置所限，IE 7 我装不了，也就无从去研究。据说 IE 7 在服从标准方面大有进步，但是从其出身考虑，我还是不抱太大奢望。等年中换了新机器，估计就能有机会一睹 IE 7 的真容了。那个时候，就要学习新的 hack 手法了。无休止的猫鼠斗争……

现在的浏览器已经够智能了——不仅能将静态的动态的网页还有位图呈现——IE 6 不支持PNG透明这个事情让我一直想不通啊想不通，客户端脚本（JavaScript就是很好的例子啦）也是支持得风风火火。现在Fx已经支持SVG图像，估计矢量图象时代也不远了。再加上一些林林总总的插件扩展，现在正热的 web 2.0 服务，浏览器做不到的或许就只有一些专业软件和工程软件的事情了吧。在这样的时候，有没有更好执行W3C的标准，似乎可以作为一个很好的衡量标准——在一个趋于世界大同的背景下，固执己见的死抱着自己的那套标准不放，Netscape 已经是一个活生生的教训。

其实IE（主要是6啦，其他的我也没用过……）的问题归结起来就是它在html标签之外又加了一个布局。一般HTML文件都是html标签为最大，里面是head还有body标签，大家各司其职。而IE在html标签之外又套了一层，使得其布局变得更加复杂。我一直觉得IE对于表格的支持远优于对CSS的支持，而在W3C大力推崇 XHTML+CSS、CSS 3都要面世的时候IE还那么固执自己的标准，真让人想笑它的迂——Fx、Safari、Opera 哪一个是省油的灯？如果IE还是想靠着windows的捆绑来保证市场的话，一败涂地只是时间的问题。

传说中IE 7进步了不少，不知道效果如何。只是希望，不要又是一场空欢喜，然后紧接着的就是一轮找bug、修bug的猫鼠战。

HTML，是超文本标记语言（Hypertext Markup Language）的缩写。顾名思义，HTML就是为了文本布局而存在的东西——它当初被发明，也是为了在最初的网络中能方便的分享文档资料，将图片、声音、文本组合在一起，而不再是散乱的一堆文件。至于后来HTML被WWW看中，成了气候，那是后话。

归根结底，HTML还是为了内容而存在的东西，毕竟它的诞生就是为了表现文档。但是目前的一个趋势是——国内很明显，国外似乎还强些，估计是 web 2.0 冲击的——HTML的表现已经大于它要表现的内容。网络的升级带来的结果是大量的图片、Flash堆砌出一个华丽的界面，内容却乏善可陈。因为我是从04年开始接触网络，以至于这么长时间以来我都觉得这是一个很普通的现象。直到我第一次看《HTML与XHTML权威指南》的时候，看到里面连篇累牍地讲解最基本的HTML标记的含义和使用场合的时候，我还会笑作者的迂腐——现在还有多少人按照标准来啊？还不是随手拈来搭个花架子了事？而随着慢慢的深入，我才终于明白了，HTML，还是内容为王。

纵观现在的 web 2.0 设计趋势，貌似已经逐渐回归到了“内容为王”的道路上——设计基本都是从简，繁复些的也多是矢量图。相对起国内的一些设计，我更喜欢国外的 web 2.0 的那种感觉：直截了当，一目了然，直奔主题。当然我也不打算盖棺定论说华丽了就是不好。毕竟还有很多专门的艺术站点，人家的卖点就是那个界面，大量的图片、Flash那是必然——谁说华丽的网站就不 2.0 了呢？

我理解上的“内容为王”，除了内容要言之有物外，还有很重要的一点是要让HTML去做它本来的任务——标记文本，布局文档。想象一下：现在把手头随便打开的一个网页去掉CSS，你还能看懂么？现在有许多的页面看着华丽丽，而去掉了CSS，整个布局便会一塌糊涂，让人无从阅读。当然，现在的人还不至于吝惜那一点点资源，也可以排除部分盲人上网使用的阅读器，但是对于很多使用移动设备上网的人来说，这样的页面就几几乎是噩梦了。为什么在设计的时候就多想一步呢？而且，其实如果一开始就很好的使用HTML标记排版，会发现CSS更好写——因为大量的东西都已经是现成的了，稍微调整一下加一些背景图片，就可以大功告成。

我一直觉得W3C之所以要把XHTML和CSS分开，就是为了突出内容为王，让XHTML只去负责内容，而将表现的任务都交给CSS。抽离了CSS，XHTML依然要能做到它的基本任务——展示文档内容——我觉得这才是设计的终极奥义。如果抽离了CSS，读者看到的就是一盘散沙，那么基本可以断定这是一个失败的设计，至少这位设计师，并不真的理解什么是XHTML和CSS。