2008-04-20
“重构”的春风吹遍大江南北，互联网一时间风声鹤唳，“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做“容器”
主菜单究竟是用<div id="mainnav"><ul>还是<ul id="mainnav">？这是一个博弈的问题。至今这个问题也没有人能够给出明确的答案，就连我也是如此。诚然，<div id="mainnav">在只包含了一个<ul>元素的时候，这个div就显得有些冗余，但有时候为了配合美工绚丽的设计，多一层标签就意味着多一层变化（有些人在a标签里套span也是如此）。而div不带任何原始属性的先天优势也是其它标签所无法比拟的。这个命题我只是想说明一件事，就是我们应该意识到，<div id="mainnav"><ul>之外，还有<ul id="mainnav">这种写法，同样具有良好的结构和语义，并且省去了一层嵌套。在我们不需要为华丽的美工劳心劳神的时候，是不是也可以让结构更加简约呢？
这个命题其实还可以引申为――“并不是所有内容都需要块元素做容器”、“并不是所有链接都需要其它元素做容器”，例如很多页面都有的“更多”。有些人写做“<div class="more"><a>”，也有人写做<p><a>或者<strong><a>。在这些“容器”只包含了一个<a>标签的时候，它们是否还有存在的必要？直接写成<a class="more">会破坏结构吗？会缺乏语义吗？会影响布局吗？换一种思路，你也许就会有不一样的收获。
4、工作上也做到“结构与表现分离”
关于这一点，网络上很多高手都是这样建议的，也就是先打开编辑器，把结构完整地写出来，再去CSS里写表现，而尽量不去动已经写好的结构。
然而以看书为主要学习方式的人却很难体会，因为关于标准的书籍多半是手把手来教的，也就是必然是结构表现结合，循序渐进。虽然有些书籍有这方面的建议，但短短的几句话远不如读书过程中的潜移默化。在制作人员能够对结构良好把握的时候，同时写结构与表现也不会对结果有太大的影响。但以我的经验，结构表现分离的工作方式，要比同时写结构与表现效率高很多，同时也不容易遗漏页面上的元素。
当然，所谓的“结构与表现分离”并不是完全不考虑表现，想要兼顾到表现，就要保证――在不破坏结构的前提下，CSS选择器能够选择到尽量多的内容。在哪些地方加class，或者用哪些标签来区分，是一个见仁见智的地方，相信每个人都有自己的体会。而结合不同的设计稿，有时候也需要做出相应的变化，然而这些变化都应该有一个同样的前提――不破坏代码的结构和可读性。
再就是，一定要意识到，任何可视化的工具都是魔鬼。它们可视化界面下所呈现的效果，往往与真实浏览器相差千里，而我们真正要兼容的是浏览器，不是编辑器的可视化界面。
5、CSS不是万能的，没有CSS也不是万万不能的
相比于CSS1.0时代，今天CSS可以完成更多的事情，然而需求永远是领先于技术的，CSS无法完成网页所有的表现层工作，有时候我们必须结合JS或者其他语言来实现一些效果。而另一些时候，用JS的方法比只靠CSS简单得多，并且代码结构更加良好――最典型的例子就是下拉菜单。这些时候，我们要说服自己，或者说服老板与客户，去采用更简单更合理的方式。因为DOM同样是网页标准的重要组成，并不是使用了JS我们的网页就降低了效率或是不再标准，恰恰相反，这是对JS最大的误解。说到这里不得不提一点，就是今天的时代，比以往更要求每个职业了解更多的相关知识，做设计的人要懂一点交互和制作，做制作的也必须了解设计和程序，尤其是JS这样的前端技术，只有这样，你和同事才能够更好地合作，个人的发展前景也会更加光明。
没有CSS，指的是当我们的网站因为各种未知的原因导致CSS文件载入失败，不要因此而慌乱，这是考验我们代码质量的最佳时机。在没有CSS的时候，如果网页仍旧保持良好的可读性，这成果要远比通过W3C验证更值得我们自豪。
