========================这是前端分割线========================

6月份由于流感的缘故，第四届D2前端技术论坛被一直延期至现在，期间有很多热心的朋友一直默默支持和关注着我们，我们非常地欣慰，也非常地感动，在这里仅代表D2论坛组委会谢谢所有关心D2以及前端行业的朋友！

这里有一个好消息和一个坏消息。

好消息：我们第四届D2前端技术论坛将在12月19日在杭州举办。

坏消息：由于我们临时决定（流感缘故）举办第四届前端技术论坛，未能确定到原定国外嘉宾的时间，加之流感还没有完全消退，考虑到国外嘉宾的安全问题，所以国外嘉宾暂不参与本届D2（当然，下届我们依然会为大家争取国外嘉宾的参与）。

第四届D2前端技术论坛的大致安排如下：

举办时间：12月19日（星期六）

举办地点：杭州 阿里巴巴园区（滨江区网商路699号滨江新园区）

详情请见：第四届D2前端技术论坛专题

报名页面：http://www.d2forum.org/d2/4/sign_up.html

报名截止：2009年12月14日 0点0分0秒

特别提醒：D2报名系统基于google 文档，如果发现无法报名，可能被墙（GFW），请尝试翻墙使用报名页面提供的源链接进行报名。

如何获知您是否被邀请？

所有报名者都会收到邮件告之是否被邀请（嗯。此邮件可能躺在你的垃圾邮件夹里，敬请留意）；
如果您获得邀请函，请务必记得携带邀请函打印件，作为您进入会场的唯一凭证，否则将不能进入会场，敬请合作。

========================这是前端分割线========================

来欣赏一下海报吧：

第四届D2海报

现在在做的项目有非常多的DOM操作，而且还有从iframe或者子窗口中向父级窗口传递DOM节点的需求。一开始，按照经验都是使用innerHTML来操作，其实后来证明使用innerHTML是最可靠和行之有效的方法，不过我在这个问题上面却绕了一点远路，想尝试尝试是否可以直接用DOM节点作为参数传递给父级窗口。

过程略~~~

结果是在Firefox、Opera、Chrome、Safari都可以将clone过的node插入到父级文档中去，唯有IE系列（IE8未验证）浏览器会在appendChild方法上报一个“参数无效”的错误，即便使用YUI或者jQuery来操作也是一样的结果，看来IE完全把它认作是其他页面的东西。当然这个外来节点还是可以被操作的，至少可以获取数据，这样我想如果建一个代理节点是否可以解决呢？事实证明，是可以的，这里做了一个很猥琐的操作：

1
2
3
4
5
6
7
8
9

if($FHD.browser.msie){
	newDom = document.createElement(dom.tagName);
	for(var i in dom){
		try{
			newDom[i] = dom[i];
		}
		catch(e){}
	}
}

不过上面这样的操作我觉得太浪费资源了，其实有innerHTML，完全没有必要这样做，试想本来就是要想让后台程序获取到innerHTML，没有必要走DOM操作的弯路。可能有人会说innerHTML在IE下会有所有标签变大写和属性丢失引号的问题，这应该属于IE恶劣行径之一，其实写两个正则表达式就可以解决这个问题：

1
2
3
4
5
6
7
8
9

//替换大写标签为小写的正则表达式
str_html = str_html.replace(/<\/?(a|abbr|acronym|address|applet|area|b|base|basefont|bdo|biq|blockquote|body|br|button|coption|center|cite|code|col|colgroup|dd|del|dir|div|dfn|dl|dt|em|fieldset|font|form|frame|frameset|h1|h2|h3|h4|h5|h6|head|hr|html|i|iframe|img|input|ins|kbd|label|legend|li|link|map|menu|meta|noframes|noscript|object|ol|optgroup|option|p|param|pre|q|s|samp|script|select|small|span|strike|strong|style|sub|sup|table|tbody|td|textarea|tfoot|th|thead|title|tr|tt|u|ul|var)([>|\s]+)/gi, function(m, m1, m2){
	return m.toLocaleLowerCase();
});
 
//为属性加回引号，并将属性名替换为小写的正则表达式
str_html = str_html.replace(/\s(\w+)="?([^">]+)"?([>|\s]+)/gi, function(m, m1, m2, m3){
	return ' ' + m1.toLocaleLowerCase() + '="' + m2 + '"' + m3;
});

不过IE的恶劣行径还没有完，li闭合标签丢失问题让我很想抽MS开发人员巴掌，大小写也就罢了，标签丢失可是大问题，这应该属于故障级BUG，为什么从IE6到IE7都没有修正呢？再扇他们两个巴掌。为此不得不再多写一个正则表达式：

1

str = str.replace(/(\/|a|abbr|acronym|address|applet|area|b|base|basefont|bdo|biq|blockquote|body|br|button|coption|center|cite|code|col|colgroup|dd|del|dir|div|dfn|dl|dt|em|fieldset|font|form|frame|frameset|h1|h2|h3|h4|h5|h6|head|hr|html|i|iframe|img|input|ins|kbd|label|legend|link|map|menu|meta|noframes|noscript|object|optgroup|option|p|param|pre|q|s|samp|script|select|small|span|strike|strong|style|sub|sup|table|tbody|td|textarea|tfoot|th|thead|title|tr|tt|u|var)>([\t\r\n\s]*)

以上均为完成项目为首要目标，对问题没有深究，尤其是IE中不能插入本文档流以外的DOM节点，不知道是什么原因，有ET路过的时候希望能留下点什么。

本文例程

在紧张地和美国同事确认此事和多方面认真考虑后，在周二网侠大会方面最终决定推迟第三届中国互联网开发者大会的举办至今年的十月份，并很快关闭了其官方网站的报名并作出了解释。我们也在第一时间发布了延期公告“非常遗憾的通知大家： 因为甲型H1N1流感疫情发展的不确定性。 原定于6月初举行的网侠会暨D2前端技术论坛将有可能延期至下半年。”@Twitter

希望广大已经报名甚至已经定了机票的同学可以谅解此次变动，虽然甲型H1N1流感在国内似乎并没有蔓延趋势，但是那么多人的集会依然令人无法放心，与会者都是从全国各地飞来的，不管是交通工具上或者会场内出现流感疑似病例都会给所有参会者造成困扰，我们并没有为万一流感出现在会场做好充分的准备，更何况这次的会议会有许多来自美国的嘉宾，姑且不论他们在会议上主题的重要性，他们航班上出现疑似病例可能性比国内参会者的航班要高出许多。我想当时网侠大会也是面对了上周一大陆确诊第一例甲型H1N1流感患者的压力，才觉得形势已经比较严重而做出决定的吧。

可能有人会问D2依然可以继续举办呐？确实，没有了Douglas Crockford和Bill Scott的第四届D2论坛，依然有着强大的阵容，包括饭否的Realazy，雅虎的Kejun，百度的金大为，腾讯的甄焱鲲，淘宝的明城，还有来自Opera的Web标准布道者Zibin Cheah足以给我们带来一届生动的D2。而我们决定同网侠大会一起延期也是经过慎重考虑的，这次的D2论坛与网侠大会捆绑得很紧，我们共用了报名系统、嘉宾安排、会场布置等等，如果从网侠大会当中剥离出来就现在的时间来看基本已经不允许了，而且失去了网侠大会的的支持，作为没有任何资金来源的D2是没有能力负担外宾们的差旅费用的（真高兴他们愿意不计酬劳地为我们带来分享）。为了还能够尽快有机会见到老道甚至PPK等大师，我们才做了延迟第四届D2论坛举办时间的决定。

到了周四，我已经收到了所有外宾们的延期通知函，然而很不巧的是那时正好家里网络坏了两天，把通知函捏在手上都没有发出去，一直到周六上午才通知了Douglas Crockford和Bill Scott，今天通知了Zibin Cheah（啊，我还一直期待着Opera主题的T恤呢！）。明天便会发出D2论坛的正式延期通知吧，因上周的延期风波直接导致了我们许多工作的停滞，如果要重开D2项目现在也显得不太可能了。已经在倒计时关头的事情戛然而止相当令人心痛，之前的许多工作和许多畅想都没能实现确实是让我比较失落，不过好在还有金秋十月的盼头，那时我们会有更充分的准备。

PS：如果时间上允许，老道依然会出席本届D2论坛的，希望所有报名的同学们一起期待。

如果单拿“设计”与“开发”这两个词来说的话，所有的开发工程师都应该应用一个Devigner的标签，所有做程序开发的同学都清楚一套程序架构设计的重要性，但是很显然这里的设计指的不是这件事儿。当然在我们耳边充斥着更多的词可能是UI Design，UI和程序之间确实也存在着千丝万缕的关系，貌似也契合微软的主旨，不过在我看来也并非这么一会事儿。

前端开发工程师们是谁？以前在公司往往前后台都是一帮技术人员一块儿写，反正只要实现了老板的功能过程并不重要，充分体现着“以结果为导向”的价值观。然而后来渐渐出现的开发瓶颈、不断增加的商业需求和日趋成熟的流程管理等等因素把前端开发工程师这个职位给催生出来，这个职位制作的东西直接面向用户使用，他们不关心网站的核心技术和架构实现，却和技术人员一样维护着整个网站的运维。简单来说前端开发工程师们需要关注的核心技术只有三块：HTML、Javascript、CSS，但实际上Yahoo的张克军给我们做了一个很好的总结——“前端工程师应该关注什么”的思维导图：

前端工程师应该关注什么（点击图片查看原图）

为什么前端开发工程师适合Devigner这个词？主要是因为上面这样图，注意图中的最下方“交互/设计”。我想没有什么开发者能够像前端开发工程师这般贴近用户了，我们直接面对着用户的操作：点击、输入、选择、拖拽都是由前端开发工程师设计的。有人可能会说这不是交互设计师的事情么？的确，交互设计师们是这方面的专家，但是交互设计师们是完全从用户需求层面出发去思考和设计产品的，他们的设计存在着一个缺陷，就是缺乏技术驱动。我们经常说谷歌是一家技术驱动的公司，那是因为谷歌很善于发掘新技术的应用和价值，他利用新技术的优势给自己创造财富是技术驱动的典型体现。这倒并不是说用户需求驱动或者商业利益驱动是有问题，而是在于表述我们在交互设计(Interaction Design)中完全可以从另一种角度去考虑和衡量。通过技术优势去创造新的用户体验(User Experience)，应该是UE当中一个值得研究的方向。

其实在日常的工作当中，由于商业指标和用户需求的双重压力，前端开发工程师可能已经背负许多交互设计的工作，而一直处于被动设计的状态。如果你时而在产品会议当中参与探讨页面的实现或者提出建议，那么你已经以一种主人翁的态度去主动设计了。不管是主动还是被动，这时的你就已经被要求了新的技能——Design，或多或少这已经成为了前端开发工程师们不可缺少的职业技能。张克军的思维导图可能还是过于关注于技术的实现而缺少了对交互设计的详细描述，同时尽管交互(ID)与设计(UI)密不可分，但切切实实是两个方向，他将他们并在一起其实并不妥当。当然上面这张图还是很吓人的，其实仅仅需要简单的几步就可以做好前端开发工程师的敲门砖。

第三届D2论坛发送的Devigner贴纸

上周和一个同事为D2(D2 = Developer + Designer? 其实不然)讨论了一下关于Devigner定义的事情，我当然主张在D2当中添加一些交互设计相关的主题和交流，实现原理和代码技巧的交流固然是前端开发论坛的核心内容，但是在此之外能够让前端开发工程师们可以学习到工作当中必备的交互知识我想也应该是D2的使命之一吧。当然，这样的想法就留给下一届D2吧。

我们需要更加简短的表单

我们每到一个新网站最先使用的绝大多数都是注册表单，网站们为了提高注册的成功率让现在的注册表单基本只需要5、6个输入框就可以完成，而把所有对网站直接价值不那么高的用户私人信息抛到当用户需要使用时才填写，这不仅仅是为了能够让用户迅速注册，还是对用户隐私尊重的表现，因此几乎所有的网站都使用了这样的做法。更有甚者连为了保证用户不输错密码的验证框都去除了：

豆瓣网注册用户

这不是最短的注册表单（曾经记得看到过仅需要填写一个Email的注册表单）但是我敢保证这是各大网站的注册表单中成功率最高的注册表单了。我挺喜欢这样的表单的，如果可以把昵称也不要，去掉确认《使用协议》的checkbox那就更爽了，不过这样却增加了一定的风险使我们注册完后发现我们的密码是不正确的，豆瓣可能借鉴了Myspace的注册无视了这群注册成功但是永远登陆不了的用户，如果是应了增加注册成功率的商业指标的话也无可厚非。

我们需要一步完成的表单

可能为了控制表单流程防止使用出错，可能处于交互的需要有很多表单并不能在一页上完成，而不得不continue到下一个表单甚至再下一个表单，我们想我们绝大多数时间都没有这个耐心去使用这样的一个流程颇为复杂的表单，有啥内容是不可以放在一个页面里面来完成的呢？在现在的Ajax技术已经非常成熟的情况下还需要使用N多个提交来完成表单是多么愚昧的想法，更甚的是那些无法修改已经提交的内容而只能重头再来的调查类表单。

多步骤表单

上面是一个典型的多步骤表单，整个流程是：下载Excel文件并填写内容 => 上传填好内容的Excel文件 => 再修改页面已经读取的内容并确认提交。我真的怀疑当时话那么大力气做这个功能是为了什么？藐视我们的智商吗？我绝对无法想像我在使用这个功能时候的状态。向这样的Batch Upload功能一定会有更好的替代解决方案，例如像Flikr那样的批量图片上传方案，尽管不可避免地使用了两步表单，但是在我们使用上来说那玩意儿好用太多了。

我们需要功能专注的表单

一个表单只做一件事是最好的，我们不会在没有目的的情况下去使用表单，所以表单要专注于他将要完成的功能，那些喧宾夺主的辅助功能只能使我们的使用更加困扰。我们期望看到是夸大突出的核心功能，这样我们在使用的时候便可以专心向原先设定的目标前进，否则花心的我们会东点点，西点点啥时候不知不觉要不让表单提交失败，要不就直接离开了。

WordPress发表文章

文章编辑器是WordPress的发产品页面最核心的内容，这个页面下面的“摘要”、“发送Trackbacks”、“自定义域”等功能都被默认隐藏了，因此更加突出了文章编辑器的位置，我们承认我们往往懒得点开被默认关闭的内容。不过WP的编辑器还有一些另用户困扰的地方，左上角的那排功能按钮添加视频和工具栏中的内嵌媒体功能似乎冲突了？好在WP这个页面的核心功能非常专注，让我们很容易就搞清楚了。

我们需要提示完善的表单

其实我们在使用表单的时候还是需要很高的学习成本的，为了可以达到我们的目标不得不忍受各式各样的新表单当中的变态要求，因此我们比较喜欢那些拥有完善提示的表单，在这些表单里面可以看到我们如何及为什么要填写这些内容。行业拥有许许多多的标准，譬如我们看到radiobox就知道是需要点击选择其中一个的，譬如我们看到dropdown list就知道要下拉选择，希望在表单当中有创新的行为的时候有明确的功能提示。

表单提示

上面是一个很传统的表单，但是表单还是对这些inputbox做了输入提示，这其实是一个很贴心的服务，熟悉的用户可能会这样的提示不屑一顾，但是从一个注册表单截取出来的图，对于第一次来访的我们，有这样的提示还是很重要的。

除了对输入提示有要求以外，我们还期望对表单错误提示有明确的指示，最近经常看到登陆表单出现这样的错误提示：

您的用户名或者密码或者提示问题或者提示问题答案有错误。

我真想把制作这个功能的人的脑袋上砸一个窟窿出来，在频繁使用cookie来记录用户信息的时代，还有多少人能够明确地记录下以上四个信息没有错误？况且我们完全可能拥有不止一个用户名，在互联网那么大的坑里面如何找到我在你这儿使用的是哪个？

我们需要脉络清晰的表单

今天看到一个发布产品的表单，顿时令我傻眼了，和之前相比他确实简短了一些，但是他的简短不是通过减少非必要字段来解决的，而是删去了表单块内容的原有的分割，这让原本很清晰的表单立刻变得让我摸不着头脑，只看见一堆表单元素展现在页面上，完全失去了之间井然有序的分块。我们可以理解一个表单当中有非常非常多的元素需要填写，但是无法忍受的是这些元素没有规则地排布的页面上面，混乱地不知从哪里开始敲打键盘。

（例图太大，不贴了）

Ebay的老产品表单有4400像素以上的高度（真是无法想象这样高的表单竟然还要分两步走才能完成，不知道Ebay那帮白痴怎么想的），这样的页面对我们来说简直就是噩梦，但是好在Ebay的表单一块一块清楚地罗列，让我们很大一部分人都能够去忍受它的存在。然而Ebay的新Simple版表单虽然将高度缩减了一半，但是仍然保留着优秀的模块分布而且在视觉上更加强化每一块区域填写的内容是什么。

等等

其实我们的要求不高，越来越多的表单也开始真正关注我们的这些需求，我们可以理解为了商业指标而放弃部分利益的手段，但是这样在短期内可能会有直接的效果，但是长期来看并不能带来真正的效益。还是要牢牢抓住以客户第一的心态来制作页面，才能真正抓住我们的心呐。

问题一、这是在做这个博客的时候发现的一个问题，万能的IE再次显示出了它的无能，虽然不是什么难题不过却总令人不爽。在一个正常流的文档当中有并列三个div分别是divTop、divMiddle、divBottom，如果divMiddle为绝对定位的元素那么对接下去的divBottom如果使用负的margin-top定位会失效[例子]。在制作例子的时候怎么也不能重现问题，经过一步步排查才发现这个问题只有在divBottom设置了高度的时候才会出现，因此解决方法很简单，只要去掉divBottom的高度设定即可，不过往往很多时候我们不能那么做。我想大概是文档流本身的问题，根据html文档流的原理设为绝对定位的元素会脱离文档流而让紧随其后的元素填充自身的位置，理论上应该不会造成定位失效所以像Firefox这类标准浏览器便完全没有上述问题，我只能认为是IE本身的bug了。而为了应对这个问题，我不得不调整文档流把divMiddle放在divBottom后面，当然这样做的最大后果便是html的语义被破坏了，还好这在我的应用当中不是大问题。——根据二八原则，至此这个问题应该告一段落了，不知道是不是我理解上有错误，有高手路过的时候记得指教。

问题二、这个问题也是伟大的IE给我们造成的困扰，不过这个问题并不发生在所有的IE浏览器上，只有在7.0版本以下的IE浏览器会出现这个问题。在《CSS权威指南》里面好似也有提到这个问题，IE6对于多类选择符的支持很有问题，经过简单的测试发现IE6在多类选择符面前只对最后一个命名的类生效因此可能会产生“伪有效”的样子，这也是为什么网络上有些同学说IE6对多类选择符是可以支持的。不过这个问题其实也要归结到我们自身架构设计的不合理上，使用多类选择符来制作CSS是比较不明智的方式，当然后果就是在今后的应用当中如果对原来的CSS不清楚便会发生制作好的页面无缘无故在IE6下不可用的情况并且很难查出根源。经过研究发现这个问题给了我一个启示，如果对IE6的hack使用这种方式做似乎便可以轻松通过CSS验证了，当然这个可用性还有待研究，况且不支持对全IE系列的hack（fuhei.net的hack方式使用了IE的条件注释工具）。——根据渐进增强的理念我还是认同CSS高级选择符、伪类和伪元素的使用的，对于打倒IE6我们坚决不能手软。

问题三、这是一个比较诡异的问题了，后来搜索网络的时候才发现这个问题是一个比较普遍存在的问题了。在使用“所见即所得HTML编辑器”来写博客、发帖子大家是否曾想过它能够导致浏览器的崩溃？在刚开始出现这类编辑器的时候我还是有一点点的担心的，但是也只是一点点而已，后来随着Rich Text Edit（后文简称RTE）的发展这一点点的担心也消失殆尽了。不过就在上周却发现即便是现在最流行的FCKeditor也会出现这个令人头疼的问题（很抱歉不能方便重现这个问题，同时忘记错误代码了，明天来贴），在某一些电脑上使用Firefox3打开RTE会导致浏览器抛出runtime error的异常，在宇宙XX同合体的google上搜索得知是因为在RTE初始化的过程当中它的父元素被置为不可见的情况引起的，因此解决方法很简单，就是保证在父元素已经在网页上可见了的情况下再初始化RTE即可。——这个问题出现在了公司网站一个常用表单的处理上，希望没有造成太大影响，现在已经被作为Firefox3的bug论处。

产品列表结构图（png太牛B了只有18K）

我想绝大多数UEDer都不会使用如上布局来实现这个模块，首先想到的当然是使用DIV[productItem]做4 × n次的循环，然而这个布局却使用程序控制每四个DIV[productItem]给它们套一个DIV[productListRow]。可能很多人都已经发现了，这个布局有一个先天性的不足，也就是前文提到的“某原因”，那就是由于产品简介的长度不同导致每个DIV[productItem]的高度不同，因此需要在每行列表后面都清除浮动以让浏览器可以做出正确排列。那么解决办法也就出来了，很简单，有如下几个：

1、最方便、最有效、性价比最高的方法就是我们当然可以知道最长长度的产品名称和产品简介，因此我们分别取这两个值排满的最高高度来作为DIV[productItem]即可，但是这个方法却有致命的缺点导致所有UEDer都不会这么做得，那就是当出现有人不填写产品简介或者产品简介填写得非常少的时候便会出现大段的空白严重影响观看阅读。

2、那就这样把，咱把“产品简介”给拿掉吧，然后使用方法1便可以完美解决问题了。这个想法非常牛B，可是它太牛B了，我绝对不敢这样操刀直接把这么重要的内容给砍掉（也许有人觉得这些内容并不重要，但是这不是这篇文章所要讨论的东西）。我对曾经抱有次想法表示遗憾和羞愧。

3、为什么不使用table布局呢？天哪我觉得这简直就是最完美的办法了，table一出八马难追的。能够自适应高度的table在这个应用上拥有绝对的优势啊，如果前端开发工程师们可以放下一点架子在html上使用它原本应该使用的结构该是多么美好的事情，我直到在写这篇博客的时候依然觉得使用table解决问题又快又省力还很有快感哦~（其实原代码中的div布局就是抄袭了table的“思想理念”了）

但是作为一个在非常牛B的UED团队的还是菜鸟的我为了要做出非常牛B的事情也为了团队的面子，怎样也不能使用上面三种投机取巧的办法来敷衍这个现实的问题吧，因此就有了这篇博客最重要的内容。

第一次尝试：

首先我们还是来考虑考虑到底使用什么标签来写这个列表吧，所谓back 2 base嘛。重新分析列表中最重要的元素有且仅有：标题、图片、简介。显然标题是最重要的，作为一个product的title存在，而图片和简介都是用来描述标题的内容，因此第一个想到的标签就是dl（请不要问我dl是什么，如果真的不知道请看这里）这样便有了以下布局（抱歉还没有时间整一个代码输入）：

1
2
3
4
5
6

<dl>
  <dt>[name]</dt>
  <dd>
    <div>[photo]</div>
    <div>[intro]</div></dd>
</dl>

对dt和dd都做float:left，dt做一个margin-top:100px来定位到图片和简介中间，dd做一个margin-left:-25%来定位到和dt相同的x坐标（由于无法输入代码就不贴css了，请看例子）这样的html是我认为最贴切的，根据现在流行的html语义化定义这样的布局太合适不过了。当然css中还是存在非常多的困难，而前面所说的“某原因”也并没有得到解决，反而更甚了，因为把标题和简介流拆开后，标题过长便会和简介的文字叠加根本无法阅读！然而经过几秒钟的思考后认为这玩意儿的解决已经超出了我的范围了。当然，有人可能会说把标题和图片换一个不就可以了么？是的，没错，但是如果这样的话使用dl标签还有什么意义呢？可能有意义吧，就是标题和简介都是为了说明这张图片而存在的，但是真的可以这么想吗？还有待实验去证明，这里就不讨论了。

第二次尝试：

如上所述，dl的存在就没意义了，那就算了吧，退而求其次使用ul（请在砸我鸡蛋前念着我还死了那么多脑细胞在这个上面的份上轻点儿吧），无序列表虽然不如定义列表来得语义那么强烈，但至少它还是和列表吧，至少不是一个division吧。ul的布局相比较就简单多了，看上去也只是把div标签换成了li而已，那么html结构如下：

1
2
3
4
5
6
7

<ul>
  <li>
    <div>[photo]</div>
    <div>[name]</div>
    <div>[intro]</div>
  </li>
</ul>

到这个时候终于要直面本文第四次提到的“某原因”了（详见“某原因”例子），如何解决li浮动后高度不同导致的矩阵错位问题？最先进入脑子的想法就是记得很久很久以前看到过一篇关于div自适应高度的文章，于是就在google翻找，当时没有收藏真是太失误了。在google搜索自适应高度那是相当多呀，但是有一篇文章是不得不借鉴的，但是这篇文章并不是适应于我们的案例，很显然它更适用于两栏或者三栏布局，而我们至少有四栏甚至五栏。自此还有什么办法可以让多列布局自适应高度呢？（请不要跟我提关于巨大的padding与负margin这件事）伪装的自适应对于需要货真价实产品的我们是没有用的……至此思维告一段落，我需要回到源头来，最开始的出发点在哪里？如果只是为了清除浮动的话？使用最简单的方法？

带着上面的问题，便渐渐有了解决方案，不可避免的，我可能需要借助后台工程师的力量了，我在每4个li之后的那个li上加上clear:left属性，以清除左边的浮动来防止它因为前面li的高度不够而导致的错位，从它之后的li就应该会乖乖地跟在它的后面了。这个想法很美好，但是很天真，可能我确实在FF等标准浏览器下面获得了预想中的效果（没有想到实现起来那么简单，正在开心中），突然发现又是那该死的IE！！！那个加了clear属性的li确实正常显示了，但是在它之后的那些继续原来它应该范的错误，没有起到清除整行浮动的作用（详见该死的IE的例子）。我懊恼了~通过漫长的研究至今已经找到了一个语义和样式都比较平衡的点却无法在IE中得以实现，怎么办？

第一个想法就是使用hack技术（虽然UEDer们都不推崇，但是为了维护之前的成果，老子发飙了），问题就是如何做hack。先看这样的例子，如果我每4个li后面都插一个<li style=”clear:both;float:none;”></li>的话，不管在IE下还是在FF下都可以完美地完成任务，但是这个方案有一个致命的缺陷，就是对原有html语义的破坏，凭什么好好的列表突然就多出一个空li来？那么能不能在不影响原来语义的情况下，在FF依然使用它应该使用的clear:left方式的情况下来针对IE进行hack呢？非常幸运的是IE给我们提供了条件注释工具<!–[if IE]><![endif]–>（我想一旦开始使用这个东西之后一定会非常依赖它的），因此html结构就变成了这样：

1
2
3

<li>[productItem]</li>
<!--[if IE]><li class="clearForIE"></li><![endif]-->
<li class="clearForFF">[productItem]</li>

希望这样子写代码可以看得懂（详见我的解决方案例子）。至此为了尽力表述完整语义的目的就达到了，因为所有的浏览器、搜索引擎和用户都会把那段IE的hack作为一个普通的注释来看待（这里也包括IE自己，这是一段条件注释，那还是注释），因此产品列表的li就没有被中途无故打断，更不会像最早的div版本每四个是一个division。到这里研究工作就算完成了（关于这个IE特有的hack的可能的严重后果木有给予考虑。。。），不过还有一些额外的思考。

其实使用division也不完全是不好，如果division这样做：

1
2
3
4
5
6
7
8
9
10
11
12

<div class="top20">
  <div class="top15">
    <div class="top10">
      <div class="top5">
        DIV[productItem]{1-5}
      </div>
      DIV[productItem]{6-10}
    </div>
    DIV[productItem]{11-15}
  </div>
  DIV[productItem]{16-20}
</div>

作为业界的晚辈，我当然很期待能够参加这样的聚会，因此在收到圆心同学发来的邀请函时切实感受到的荣幸倍至直到现在依然还在自己小宇宙的某处荡漾着（好似我废话很多，这其实是想引证一下在周五晚上下班后坐上“幸福班车”油然而生的兴奋充斥了头皮）从不到一年前刚刚踩进前端这个行业到能够在第二天进入到国内前端技术行业领先的大型学习交流会简直有如做梦般不可思议，就好像看到精心培育的风信子终于开出了艳丽的花朵一样。

D2贴纸

第二天清早我们一行9个人8点就起来打点行装前去会场锦江国际酒店，本以为已经算是比较早到的一批与会人员了，不料taobao和中文站的同学早已来到会场。会场早已布置好了两块大屏幕分别显示演讲者的演示稿和叽歪网线上直播，据说这次D2的报名者达到了600人之多，大大超出了主办方的预料因此不得不临时更换主办场所，而与此同时也不得不委屈近50%的前端技术爱好者仅发了300人的邀请，为此特意开辟了叽歪网的D2forum来为没有能够到达现场的同行们同步传达会场的内容，这里要特别感谢主办方土豆网的细心设置。

来自Adobe的7yue同学分享的Flash10

这次D2论坛的主题是“前沿技术与前端协作”，在上午的两场讲演中，来自Adobe的7yue同学为我们带来了新鲜出炉的Flash10技术分享，Flash10诸多的新特性和十分牛X的方方面面都在早上1个小时的分享当中展示出来，其中的Pixel Bender工具真是令与会同学们大开眼界，至少在他牛X的Apple Air上轻松地运行这些动态视频像素级渲染看起来是多么的美好，可以看得出7yue同学为此做了充分的准备，它作为演讲嘉宾为这次的D2带来了绚丽的开场。我们都能认识到作为新生的行业，前端技术是一个飞速发展的技术，掌握前沿技术的重要性毋须质疑。

来自Microsoft的超群同学IE8和Silver Light分享

同样属于前沿技术分享的来自微软的超群同学给大家带来的IE8与Silver Light的新特性分享是一场非常有趣的分享，不管现在的IE产品有多么的令人诟病，但是看起来即将到来的IE8被寄予了大群博士、博士后开发团队非常大的期望，而超群也为我们展示了足以令人对IE有所改观的新特性和功能。而Silver Light在高清视频流媒体上的NB程度简直令我乍舌了，源生支持H.263和mpeg4编码的Silver Light的运行速度其实有点令人担忧，但是超群同学的演示似乎并没有那么困难，只是电脑硬件条件符合了要求是没有用的，祖国的网络硬件条件啥时候才能满足在线观看720P的高清视频呢？

来自Alibaba的Justin同学分享

另外的四场分享都针对着“前端协作”这个主题，开发协作其实一直是所有技术开发人员共同的问题，前端必然需要直面这个严肃的话题。来自土豆网、淘宝网、Alibaba的同学分别分享了各自团队的协作经验。也许很多人觉得团队协作是主管们要考虑的事情，而自己只要做好技术的本职工作就好，因此当天在会场上听到了许多表示希望可以听到更多技术分享的话题，这个希望下一届的主办方可以多参考民众的需求吧，充分发挥UCD的理念。同时晚辈也觉得四位老大们分享的前段协作似乎稍微不够浅显了，也难怪会有异样的声音。

因为不可抗拒的原因，论坛比预计的时间提早了1个半小时结束，直接导致我们无敌男人小组的不知所措，车票已然定好，剩下的时间就只能在候车室打法了。终于能够把握这次机会坐上一趟和谐号了，可惜乌漆抹黑的晚上根本无法享受170KM/H的快感，只能在睡梦中消化白天的学识了。

D2归来的和谐号列车

最后，所有D2的资料都可以在http://www.d2forum.org/2008/12/04/look-back-upon-the-third-d2-forum/这里找到。下一届的D2会回到杭州，期待能有更多的技术交流了。

PS：期待IE系列贴纸

《超越CSS》(Transcending CSS)

这本书超贵的69块钱一本，还好我这本是借来的，即便是300多页彩印铜版纸也用不了那么离谱的价格嘛。。。不过好在书的内容确实很好，不仅介绍了许多CSS的技巧和基本的设计准则，而且还为读者敞开了一扇新的大门，它以CSS的视角放眼整个web的设计和开发过程，创造好的版式、好的交互、好的代码、好的流程。超越CSS是每一个优秀的web设计师都必须做到的，所谓在遵循规则的基础上打破规则才能创造出最优秀的作品。

首先我们要遵循的规则便是：CSS是一个非常优秀的定义样式的工具，但是我们不能要求所有的使用者都能够顺利地从你设计的CSS界面当中获取合理的排版信息和漂亮的图片说明，因此我们必须创造出一个在没有CSS状态下也能够顺利被阅读的文档。在这个基础上我们需要使用合理的标签去标记内容，请尝试把生活当中的所有物品都标签化吧，这将对今后的设计有很大的帮助。

其次我们需要一个好的工作流程：收集内容->框架图/灰盒->静态设计->交互原形->有意义的标签->CSS编码/JS编码。要注意的是CSS工作可并不只是CSS编码那么简单的事情，每一个CSSer要把自己放在一个设计师的角度来看待整个设计才能创造出优秀的页面，往往视觉设计师只是注重了视觉的效果，而你作为一个CSS设计师则需要更加关注内容的突出表现、用户的交互甚至搜索引擎等等更为细节的内容，而这些内容都建立在内容排版之上。

那么接下来如何创建一个优秀的排版呢？我们可以引入网格的设计，我们可以在任何你想得到的地方使用黄金比例和三分之一规则，而更能吸引人的地方便是在遵循网格的基础上突破它，创造出令人意想不到的版面设计。我们可以去参考新闻报纸，那是最最基本的网格应用，几乎早期的所有报纸都遵循8列或6列的网格版面，而今的报纸则更加多元化，在那些花哨的广告和醒目的娱乐头条上都能找到网页的设计灵感。同时我们还可以在杂志、唱片店、剪贴簿甚至Flicker上面寻找创作的灵感。

真正的超越CSS不是在一些常规的或者旁门的小技巧上的应用，而是不被现在的CSS规则拌住了脚，譬如我们总是以为：唉~这个设计太麻烦了~CSS的编码会很痛苦的~还是算了吧~；再譬如我也总是想着：我要让使用任何浏览器的用户看到的都是一模一样的优秀设计~，这些都是非常愚蠢的想法，而要改变这样的想法仅仅需要记住超越CSS就可以了。。。

CSS和CSSer们一样的年轻，可CSS3已经指日可待了，那么在超越CSS的最后还是让我们期待这个优秀的样式设计表继续在未来的浏览器甚至应用程序中发挥出巨大的作用吧。

PS1：如果想买这本书可以在卓越网获得75折的优惠。

PS2：自从这本书以后便多去关注了一下相关类别的其他书籍，发现人民邮电出版社是非常王道的，因此可以直接去新华书店的人民邮电出版社专柜。