大约两周前我问 @felixding （丁宇）有没有证明 <div> 比 <table> 好的现成资料，他提到其实“就现在的大部分需求来看，table 布局没什么不好的地方”，我说我有些观点——也就是现在准备写的这篇东西，可以作为推特上那个未完的交流的延续。
这个事情的背景是，我最近在和一个年轻有冲劲、但是比较内向（也就是说，和外界的交流不多）的团队一起工作，课题是一个服务型的网站，除了完成软件产品之外，我还希望能够在开发方法和流程、甚至氛围上能够有个提升。
在工作开始之后不久发生了一个问题，这个团队中的某个小组，只有一个网页设计师，但是有好几个熟悉J2EE后台的程序员，结果他们都在等网页设计师一个个的出HTML原型页面，于是有了类似这样的对话：
问：为什么不自己出HTML？难道你们不会？
答：我们会，但是我们出不了美工（注：这是他们对网页设计师的称呼）那种页面，我们的HTML最后还会被美工改的面目全非，出现一大堆问题，我们还要重新写业务逻辑的部分。。。
问：为什么不约定一个HTML线框（wireframe），然后各自去做内容和样式的部分？
答：那是什么？
经过了解，网页设计师很久很久以前就曾经提出用 div 来定位的建议，但是由于不够系统也没有坚持，所以没有成果，结果这个团队2-3年以来一直是用老式的 table + gif 来做页面框架，作为面向服务的EIP门户网站，其元素和结构都相当复杂。
那时候我只是大致的知道，HTML的进化方向在于语义的强化以及内容和展现的分离，这在企业架构上会带来更好的模块化，对内容的重用和聚合都有利，而具体到 <div> vs. <table> 的问题，要说服一个工作了多年的团队放弃看上去没有什么问题的模式并不简单，况且对于目前大部分需求来说，<table> 确实看不出有啥不妥——而 <div> 定位更像一种“结构化写作”，就好像和 Word 比的 TeX 一样，是有一定的学习曲线的，他们的组长就问过我：我用 DreamWeaver 几分钟就可以完成一个复杂页面的 <table> 布局，用 <div> 好像找不到什么可视化工具。。。
我花了一些时间做了准备，然后要求小组的成员仔细研究这份文献（这是Scott Design的Bill Merikallio和Adobe的Adam Pratt两位专家在2003 Seybold大会上的主题演讲，拥有有趣的插图、精辟的文字和详实的实例）：
Why tables for layout is stupid: problems defined, solutions offered （中文翻译）
这篇文章中提出使用 div 的优势包括：更小的页面size（载入变快、节约流量），更容易修改（页面布局和样式），更加“搜索引擎友好”，更容易制作移动设备版本的页面——我想补充一点：更容易模块化以及随之而来的协作流程上的灵活性。
然后我们进行了多次的讨论，并在一个小的模块中进行了尝试，具体做法是：
1. 做出只包含页面内容模块的线框HTML，产品设计师、页面设计师和程序员一起做，很快的确定下模块所需要的所有页面框架，里面是一组 div 标签，按照业务的重要性和嵌套结构排列。
2. 页面设计师根据这个线框HTML制作对应的样式表，包括用于定位的样式表、用于外观描述的全局样式表和页面样式表等。
3. 程序员完成后台代码编写，目标是生成各个 div 里的内容。
4. 页面设计师输出定位样式表、全局样式表等阶段性里程碑时就给程序员去验证，最后再合并成果做模块级的验证。中间有过一些问题，两边的版本出现了差异不过很快就修复了。
上周五进行了一次总结性讨论，下面这些体会来自小组成员：
* 网页设计师：页面更小和更干净，原先的主页仅HTML就有近150K，改造之后只有80K左右。
* 程序员：进行布局的调整更快一些，更专注于内容本身的构成；被强迫进行“这些内容可能会以完全不同的方式被展现”，开始不太习惯，但是一段时间之后发现很酷！
* 产品设计师：可以更早的预览内容和业务流程。
* 需要一套标准化的规范，定义线框HTML的标准元素；需要一个页面元素库来缩短构造常用模块的时间。
* 沿着这条路线继续下去，网页设计师和程序员的沟通会更有效，因为把各自最专业的部分一定程度上屏蔽掉了，线框HTML是双方易于理解的概念交集。
老实说，有些发言甚至超出我的预期。
下面是我自己的感想：
当一个团队决定从一个技术/机制/方法转向另一个的时候，大凡有两种可能：
1. 被迫的、快速的切换：比如，某产品被证明无法提供所需要的功能或者性能或者可定制性，经过验证的另一产品是可行的替代品，那么无论多大的代价，都会立刻进行切换。这种事情没人喜欢，但是也没啥更好的办法——谁能保证自己的技术决策永远正确？
2. 主动的、渐进的切换：一个比另一个具有一连串微小但实在的优势，但另一个也能完成几乎所有工作，这时候启动切换是非常难的，因为没有足够的动机和动力。对这种情况来说，合适的时机（例如：某个激起大家思考的问题，规模恰当的项目，找到称职的实验小组等）和强有力的evangelist是必要的基础。
（写到这里感觉有点像国际象棋里所谓的战术派和局面派，前者是一锤定音的战术组合打击，后者靠的是逐步积累微小但是实在的局面优势——中心兵型更优、双象、开放线控制等等，哈哈！）
其实我同意，<table> 并不是不可用，但是当出现机会的时候，要毫不犹豫的推动这类渐进式的技术变革，而不必太在意当前的投入产出比，只要预算许可，越早越好，收益越多，尤其还有些习惯性的问题是需要时间去逐渐解决的。