为后代选择器和ID选择器而辩护

【本文译自 Zeldman （作为前端工程师，不要告诉我你不知道他是谁）在2012年11月写的《[url=http://www.zeldman.com/2012/11/21/in-defense-of-descendant-selectors-and-id-elements/]IN DEFENSE OF DESCENDANT SELECTORS AND ID ELEMENTS[/url]》。】


除了偶尔更新下《Designing With Web Standards》，我这些年已经不再写关于CSS和HTML的具体实践和细节问题了。长江后浪推前浪——其他设计师和开发者接过了我的枪。在很大程度上，无论对他们还是对我们这个行业，这都是件好事。要说清楚代码那些事，最佳人选永远是那些每天花25小时沉浸其中的家伙——我也曾是如此。当像我这样的老家伙转向战略和管理角色（让我们有新的创新领域，也可以有新的写作主题），新一代代码高手也继续着发现和传播新知。这就是生命的神奇轮回吧。

不过在这诸多美好之中，我偶尔也会发现狗屎。有一种观念——如今甚至已固化成信条——即所谓[url=http://csswizardry.com/2012/11/code-smells-in-css/]应该避免使用id[/url]——因为id“specificity【特化度】太高”——用class总是更可取。对这一信条，我必须称之为——胡扯。

据我所知，此观念来自于Nicole Sullivan著名的[url=https://github.com/stubbornella/oocss/wiki]面向对象的CSS[/url]。这种书写HTML和CSS的方法论被设计用于规模达数千页面的网站——且这多达数千页面的网站是由多达数十个前端工程师经过数年时间建造出来——且通常这建造过程缺乏统一准则或样式指导方针（或者等到有统一准则和样式指导方针之时已然太晚）。在这样的网站上——在像Amazon或Facebook这样从一开始就一锅乱炖的网站上——因为他们有一大帮厨子却没有一个主厨——在这样的网站上，使用id和后代选择器的组合确可能引发问题，特别是当笨拙的码农试图通过创建更specific【更特化】的后代选择器规则来覆盖基于id的后代选择器规则的时候。

在这样特定（而奇葩）的环境下，开发者们不断决斗般的把一条又一条css规则加入到巨大的一坨样式表里，这样式表更像考古遗迹，而非现代代码的好范例。面对如此一坨，Nicole告诫避免基于id的后代选择器或许是明智的。如果你倒了血霉要去弄一个庞大的、开发得一塌糊涂的网站，又不被允许按照常识和最佳实践重构模板和CSS，你可能不得不依靠class而弃用后代选择器和id。

但在几乎所有其他环境下，正确运用id和后代选择器更可取，因为这样更富语义，也更节约带宽。

我一直以来所主张的使用id的方式，其实就是HTML5新增元素的前身。2000年时，我们没有footer元素，为了给该div中的内容赋以结构上的意义，我们这样写：div id="footer"。今天，根据人们访问我们网站所用的浏览器和设备，我们可以选择用HTML5的footer元素替代老方式。但若是我们不能使用HTML5元素，使用id也没有什么不对的。

至于后代选择器，只要这个网站不是由100只猴子设计的，我们完全可以假设开发者能以协调的方式对具有id的div或者HTML5元素内的后代元素赋以样式，并且处于不同id的div或HTML元素中的相同元素可以被赋以不同样式。比如footer中的段落和列表项跟aside中的段落和列表项就可以被赋以不同样式。id（或HTML5元素）和后代选择器就是用来干这个的。给sidebar中的每个段落元素都设上classname不仅无谓浪费带宽，更是粗鲁之极。

跟我念：id没有任何问题，只要你正确运用（表达语义、表达结构、不滥用）。认为class总是比后代选择器和富有语义、表达结构的id更好，这种观念全然谬误。

请注意：我不是在贬低我的朋友Nicole Sullivan的面向对象的CSS对于那些一团乱麻的网站的作用，正如我不会贬低挖掘机对清理灾难现场的作用。我只是不想用挖掘机来清理我的房间。


【完】