经验之谈！解读Div+CSS网页制作误区

“重构”的春风吹遍大江南北，互联网一时间风声鹤唳，“div+CSS”俨然已成为一种“时尚”，难以尽数的网站都不约而同地开始了自己的“重构”。然而打开这形形色色网站的源代码，却时常令人哑然失笑——

我们看到有嵌套6、7层的div布局，有不用table的表格，有纯div+a构成的页面，有成百上千的表现层class……现在关于标准的书籍越来越多，除了少数几本标榜“高级技巧”的书籍以外，很少有人不会在自己著作的前几章强调这样一句话——“结构与表现分离”。然而这些书籍的读者们，又有多少人认认真真地读过前几章呢？还是更多地直接跳过那些乏味的结构讲解，一头扎到貌似高深的布局技巧与Hack中去？

其实div+CSS这个说法从一开始就误导了太多的人，急功近利的心态则更是造成这种现象的罪魁祸首。一个习惯了table布局的网页制作接触标准的第一步，不应该是去盲目寻求实现各种布局的CSS技巧，而是努力改变自己的思维方式。

下面将结合我的切身体会谈一谈顺应标准的思维方式，其中有不少是我曾经走过的弯路，希望对刚刚接触标准的XDJM们有些帮助：

1、“节省代码”是营销手段，不是宗旨

“使用div布局可以比table布局节省更多的代码”，我在很多书籍和网站上见到过这句话。这句话本身是没错的，可以“节省代码”的确是网页标准化所带来的好处之一。然而切记，它只是“好处之一”，而不是“唯一好处”，更不是宗旨。“节省代码”更多的时候是我们用来说服那些顽固不化的老板的营销手段。网页标准化的唯一宗旨是“结构与表现分离”，而绝不是为了节省代码而节省代码。我曾经因为网站边栏甚至主体内容的表现形式相同而采用了统一的class （至今还有一些书是这样教的），这样的确比分别命名id更节省代码，然而这样做的代价是代码失去了良好的结构。失去良好结构的后果是：一、源代码没有了可读性；二、网站增加了未知的维护成本。试想，当某一块内容因为需要而作出表现形式的变动，例如链接的颜色等等，我们就不得不去修改页面源文件，增加额外的class，工作量比起只需要调整id分组就大了许多。而且长此以往，结构将会越来越差，形成难以逆转的恶性循环。

还有一种情况，出现在id的命名方面，也是本人曾经犯过的错误。那时为了“节省代码”，而把主菜单命名为“mm”，二级菜单命名为“m2”，三级菜单为“m3”，结果严重降低了网页的可读性，使其他同事很难接手，图省事却累了自己。同理，文件及文件夹命名方面也不宜过简，象《网站重构》里建议把图片都用“i”目录存放，个人以为并不可取，除非你能为这种高度缩写的目录结构撰写详细说明并保证每个相关人员包括其他制作人员、开发、甚至懂行的老板……都能理解和执行，否则只会给你自己增添不必要的麻烦。

2、ID是狙击枪，class是双刃剑

想要做好网页结构，id与class都是必须熟练掌握的，所谓“两手抓，两手都要硬”。ID就象狙击枪一样，可以帮助我们精准地定位要想要加载样式的元素；而class则是侠客的佩剑，信手拈来更加轻盈灵便，两者的结合能够实现结构良好且表现丰富的页面。然而现在有一种错误的观点，就是id完全可以用class来取代，事实上许多网页源代码也的确如此，打开来通篇class，找不到一个id。造成这种现象的理由有很多种，然而自table时代传下来的根深蒂固的“class=CSS”的观念才是本因。的确，class比id用途更广更灵活，但也必须意识到，class对于构建良好的网页结构远不如id有效。id的强制唯一性使得我们可以很容易通过id检索到我们需要的任意模块，而class则没有这个优势。虽然我们可以为模块定义唯一的class名，但前提是——只有制作者本人可以动网页样式。否则换一个稍微懒一些伙计，看到样式相同便直接把前面的class拿来套用，其结果就是我们发现网页里有十几个模块都叫做“gonggao”或者“xinwen”，以至于为了区分还不得不加上大量的html注释，这样的结果显然并不是我们想要的。再者就是前面提到的，通过通用class所节省下来的代码，又不得不在每个单独定义的class中挥霍掉。

ID是狙击枪，class是双刃剑，合则两利，分则两败。

3、并不是所有的内容都需要div做“容器”

主菜单究竟是用