12月26日，第三期web标准化交流会如期举行，这次会议有所不同的是，讨论的方式不再是集体会议，而是分组讨论。从现场的情形来看，分组讨论有它好的一面：一是有很多在集体会议上较少发言的人，在小组中发言会相对踊跃一些；二是小组讨论比集体会议在时间上更容易控制。
不过相对于它的弊端，这种优点几乎可以忽略不计。在我看来，缺点有以下几点：
一、不同的声音很难发出来。其实现场也可以看出来，每个时段的分组讨论，三个小组的结论基本大同小异。其它小组究竟如何讨论的，有没有反对的声音很难被听到，因为如果有不同意见需要公开发言，这个时候很多人就会退缩了。
二、无法保证小组人员的均衡。能力不均衡，会造成有些小组成员收获不大，达不到交流会最初的目的。观点不均衡，会造成有些小组讨论激烈而有些小组观点一边倒。所属公司不均衡，小公司的成员无法了解大公司的情形，大公司的成员无法了解小公司的现状。
三、按提纲讨论，时间固然容易控制，但讨论内容便难免死板。最终往往得出一堆和稀泥的结论，缺乏思想上的碰撞，使得交流会的趣味性有一定程度上的降低。
言归正传，其实这篇文章，不是会后总结，而是会前总结。是我在会前列出的一个小提纲，本来打算在会上分享的，不过由于没有公开分享这个环节，也就作罢了。当然，通过在交流会上的聆听和观察，我也打算修改一下自己的提纲。
这篇文章本来的标题是——页面重构中常见的问题，我决定把它改为现在的“老生常谈：还是思维方式”，是因为我觉得思维方式，仍旧是web标准化发展最大的拘囿。两年前我曾经在蓝色理想论坛发表过一篇文章《网页制作，改变你的思维方式》，年深日久，帖子已经不好找了。不过我发现，被岁月掩埋的不仅仅是一篇帖子，事实上过去了整整两年，前端开发领域的思维方式还是存在着许多的问题。所以我在这里老生常谈一下，如果思维方式的问题不解决，整个前端开发的社会地位，也就无从谈起了。
一、网站重构目的是什么？
相信很多人都知道答案——结构、表现、行为的分离。然而在现实中，我们大多数人却并没有这样的意识。事实上在我看来，许多人仍旧把“节省代码”作为网站重构的第一目的，甚至是唯一目的。我的一个同事，他在写一个菜单的时候，用“<p><a>菜单一</a><a>菜单二</a><a>菜单三</a></p”这样的结构，我问他为什么不用<ul><li>来写，他很茫然地问我：“这样写不是更节约代码吗？”我忽然发现，如果不回到网站重构最初的目的上，自己根本无法反驳他。
是的，“节省代码、节省流量、节约成本”，这是一个多么冠冕堂皇的理由，这是我们当初费尽九牛二虎之力说服老板放弃table采用div最大的理由，然而我们很多人却没有意识到，这个理由现在已经完成了对前端开发领域可怕的洗脑。我们为了这个理由，可以放弃合理的结构，可以大量使用表现层代码，可以用*{margin:0;padding:0;}去覆盖所有我们知道的不知道的用得上用不上的标签，可以用overflow:hidden清除浮动，可以用“class="pt5 mt5 white"（注，三个class分别对应padding-top:5px、margin-top:5px、color:white）”，只因为这个理由。
然而我们真的需要如此吗？从table到所谓的“div+css”，我们的代码量已经缩减了一大半，而有了压缩的技术，更使流量节约了7成以上。在我们已经为老板节省了这么多成本之后，还在几kb字节上吹毛求疵，是不是有些矫枉过正了呢？我们需不需要为这几kb的字节量，放弃网站重构最初的目的？说的功利一点，就算你写的代码里多出了这几kb的字节量，老板就会扣你的薪水吗？在省去这几kb代码的过程中，你得到了什么，又失去了什么呢？
好，现在，打开你为网站书写的xhtml以及css代码，认真地看一看，“结构、表现”分离，你真的做到了吗？
二、什么是“前端开发”？
其实这是一个很泛的命题，不过不管是经常在论坛上交流，还是参加web标准化、webRebuild、D2这些线下交流会，都会有很多人总结前端开发的技能结构，它应该包括xhtml、css、js&ajax、flash、seo等多个方面。如果前瞻性一点，我们还有html5、css3……。和朋友交流的时候也提到过，前端开发是需要同时兼具逻辑思维和形象思维的工种。总而言之，前端开发是需要掌握多种技能的、前途无量的、应该取得更高社会地位的职业。
好，白日梦做完了，现在我们回到现实。事实上，从参与交流会的成员也可以看出来，如今所谓的“前端开发工程师”，保守估计，百分之六十以上都还是“页面仔”。我们做的工作，只是把美工提供的图片转换成xhtml+css的页面。形象思维？那是美工的事。逻辑思维？那是程序员的事。js？那是js工程师的事。flash？网站用得着吗？seo？那是什么……
这就是现状，这就是大多数“前端开发”从业者如今所从事的工作，这样没有技术含量的工种，谈何提高地位？css不是拯救我们的法宝，它的门槛很低，真的很低。回到第一个问题，我们可以对老板：我们的工作为你节约了流量，你应该给我们涨工资。老板怎么回答？他说：你走吧，我用你一半的薪水，雇一个应届毕业生，照样可以做你的工作。他是对的。
css技巧，就是前端开发的八股文。我们可以在这里面做很多锦绣文章，但最终会被时代所淘汰。我们的目光应该更远一些，其实那些前端大牛们已经给我们指引了前进的方向，就是之前提到的js、flash、seo，还有他们没有提到的，未来可能属于前端开发领域的许多技术。这些都是“大前端”概念中的技能，都是我们应该掌握的知识。css就如同木工里的板凳，它是入门的手艺，你应该把它做好，这是必须的。但板凳不是木工的全部，如果一个人只认准了做板凳，那他不可能是一个合格的木工。同理，一个只会切页面的人，也不是一个合格的前端开发工程师。
三、说一点具体的吧。
到这个问题的时候，我又翻看了一下自己最初的提纲，我发现其实所有的问题，几乎都和前面的两点有关，索性在这里一起讲了吧。
1、关于id和class的使用。
在会上听到一些观点，说id是给js组用的，所以自己只用class云云，而且这个观点还很普遍。我想说的是，首先，js本身就是前端开发的一部分，这个前面提到了；其次，即使在公司里，js组和前端开发组是独立的，依然可以通过沟通，达成统一的id命名规范。而实际上ajax所需要的id，和我们结构中所用到的id，通常是不冲突的。下面是我在id和class使用方面的心得——
body必须加id，而同一个功能流程下的页面，使用同一bodyid，而以不同的bodyclass区分。命名应与页面相对应，统一使用“b_”作为前缀，以示区别。例如<body id="b_pay" class="b_step1">对应网页pay_step1.html
结构框架部分，统一使用无前缀的id，结构如下：
<div id="wrap">
<div id="head">
</div>
<div id="body">
<div id="column1">
</div>
<div id="column2">
</div>
<div id="column3">
</div>
</div>
<div id="foot">
</div>
</div>
除以上列举之外，不允许任何无前缀的id。
固定的功能模块，统一以“m_”作为id前缀，同一类型的模块，如同为排行榜，则加class进行编组，同样以"m_"作为前缀。
功能模块内部，除js需要外，不允许再加id，一律以class作为不同部分的区分，class均以标签实际内容命名，例如class=name、class=date，而禁止以表现命名，例如class=white。说到这里，扯一下微格式，其实结构化class命名，为扩展微格式也提供了良好的基础。
功能模块内部js需要使用的id，统一以“js_”作为前缀。（这里具体情况具体分析，仅供参考，多数时候应该和js组的人沟通协商）
所有弹出层写在<div id="wrap">之后，统一以“j_”作为id和class的前缀。
最后，所有id和class尽量以单个英文单词命名，如果必须使用多个英文单词，则以“_”分隔
2、关于css的编码格式
我个人的习惯是每个属性一定要单独占一行，这样排版清晰，也便于管理。然后书写的时候，是把纯表现层的font-size、color、background等放在最前面，盒模型相关的随后，width、height、padding、margin，最后是float、display等等。
css在书写的时候，除非是两个相邻并且样式高度重合的模块，否则不进行样式编组。因为css有一个“喜新厌旧”的特性，代码顺序至关重要，过度的编组会严重扰乱代码正常顺序，对二次开发造成恶劣影响。
同一模块的css，在最开始的地方加注释，但结束的地方不需要，因为下一个注释就是这个模块的结束部分。
3、关于结构方面
这里回到第一个大问题，好的结构绝不是代码最少的结构。在我看来，好的结构，应该是没有冗余，并且在加工过程中改动最少的结构。也就是说，我们需要一些看似“不需要”，但又不破坏结构合理性的div来兼容各种并不过分的设计。例如12月12日webRebuild上张克军分享的分层语义化模板，就提到了一种非常好的结构。他在每一个功能模块之下的head、body、foot三个div，看似并不是必须的，但一来可以良好地阐述结构，二来可以兼容一些较复杂的设计方案。相比而言，如果一开始在结构方面“节省”了很多代码，当拿到设计图的时候，就只好再拿html开刀。很多时候，我们抱怨美工设计图如何如何难切，其实如果结构方面兼容性更好的话，一定程度上是可以解决这个问题的。
忽然想到一个也许不太恰当的比喻，其实写页面就像盖房子。我们写html的时候，其实就是在搭建房子的框架。而切图和写css，就是为房子进行修饰，例如粉刷墙壁、为屋顶铺瓦等等。这个时候，我们忽然发现，设计图纸上有一个烟囱，而我们在搭房屋框架的时候没有考虑这个烟囱，缺了一根横梁，这个时候我们还可以去动房屋的结构吗？
当然，写页面的时候是可以的，电脑的ctrl+z功能包容了我们很多的错误——只是，那个烟囱，难道一开始我们真的想不到吗？
最后是广告时间
，请大家关注web标准化交流会——http://www.w3ctech.com/
