再谈某些所谓CSS最佳实践

最近看了国内某位前端工程师今年出版的新书，其中讨论CSS的部分提出了一些观点，罗列如下：

1. 用class命名表现从属关系，如.myList-lastItem（表示.myList列表中的最后一项）；
2. 团队开发中用工程师名字作为前缀区分是谁写的样式，如.hax-list（表示是hax写的一个样式规则）；
3. 前两者结合可能产生较长的class名，如hax-subNav-item-select，但作者认为利大于弊；
4. 推荐挂多个class，特别是挂若干个“通用原子类”（即通常只包含单个样式规则的class，如对应font-size:12px的.f12），比如<div class="f12 red box">；
5. 为了避免margin-top/margin-bottom可能的紧凑处理，建议不写margin，而是在标签里附加设置margin的原子类（如.mt10、.mb20），并且不要混用；
6. 为保证样式容易覆盖，CSS选择器要specifity尽量低，所以就需要有多个单class选择器的样式规则定义，然后元素上绑定多个class。


很遗憾，这些围绕class产生的实践，都是我称之为“Anti-Pattern”的东西。

我们必须时刻牢记class属性的作用。它的最佳用途是对标签语义的细化。凡是违反这一条的，都是不推荐的用法。HTML5规范这样说：
...authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.

在上述所有这些“问题实践”中，最根本的源头其实就是所谓“通用原子类”，也就是类似我之前批评过的MetaCSS的做法。显然，“通用原子类”正好是HTML5规范里所说的描述呈现效果而不是描述内容的性质。这个问题这里不再赘述，可看我之前的评论。

这里要剖析的是另外几条。


首先说第6条。为什么希望specifity低呢？其实这里的因果关系被悄悄的倒置了。并非是因为要specifity低所以要多class，而是倒过来——因为第4条——希望在一个元素上绑定多个“通用原子类”，所以才要specifity低！

正如我以前指出过的，<li class="f12 red">实际的意图是<li style="font-size: 12px; color: red;">，也就是f12和red是inline样式的缩写，所以不希望被其他样式（比如.myList li里的规则）所覆盖。问题是.f12和.red的实际specifity相当低，很容易就可被覆盖。结果就出了这样削足适履的一条，要求specifity低。并且实际上就是鼓励退化为只用单一的class selector。这样一个是不鼓励写出.myList li这样的规则，此外因为都是简单的单class规则，那么一个元素最终的样式就非常一目了然，因而很容易倒过来确保“通用原子类”不会被覆盖。

实际上回过头来想想，抽象的要求“样式容易被覆盖”本来就是很奇怪的。CSS之所以叫CSS，其独特之处就是cascade机制。退化到都是平级的单class规则定义，实际上就丧失了CSS的的power。


再说第1条。之所以要在class里表现从属关系，表面上是为了避免团队合作中的冲突——比如认为有人会直接更改.lastItem的样式，而影响.myList .lastItem的样式，但实际上这个原因是很牵强的。为什么有人会直接去改.lastItem的样式，而不是写.otherList .lastItem的规则？作者的原话是“如果多人合作，工程师B可能习惯直接使用.lastItem”。但是这是什么“习惯”呢？作者就没说。其实你知道了，还是因为“通用原子类”，及由此导致的第6条。大量使用“通用原子类”的后果其实就是习惯于退化到都是平级的单class规则定义，也就是classitis（多class症）。

注：其实就算用“通用原子类”或MetaCSS，让其回归为inline style的缩写形式这样一种本源，本来是有更好的方式来避免specifity问题的。你想到没有？


然后说一下第5条。margin是一个有用的特性，当然前提是使用者了解文本排版中margin的意义。这里作者却只是视其为麻烦。这其实只说明了一点，那就是作者不知道margin的用途，或者认为margin的用途是无聊的——比如只关心最终样式的呈现，而不管设计意图。

所以这里一个需要考虑的问题是，CSS的可维护性从哪里来的？如果所有HTML和CSS每次都是全部推倒重来（许多公司的改版大概就是这样的），那么去关心和维护设计意图确实是没用的。这里根本不存在“维护”。否则，如果我们认为设计会逐步演化和发展（并且与文档内容和结构具有一定的独立性），那么显然真正反映设计意图的CSS会更具有“可维护性”。


最后，剩下2条，关于开发者名字作为class前缀的做法，请读者自行考虑。

评论

5 楼 hax 2010-12-23  

@3楼 这个提议肯定不会被CSSWG接受，但是类似的处理可以在另一个层次解决。如我提到过的lesscss。

4 楼 hax 2010-12-23  

@2楼 你可以看看老赵最近的介绍。另外D2上有两个分享是讲有关异步模式的。关于Future模式我也想再写一篇blog来说一下，不过大概要到明年了

3 楼 rekey 2010-12-23  

这可能是一种倒退。不过我觉得css似乎也可以考虑能一些所谓的继承机制来处理这些所谓原子类的事情，据说有一些人已经提交了类似的东西。。
code :

.f12{
font-size:12px;
}
.mod .item{
include(.f12);
color:#ccc
}

2 楼 shewa5337 2010-12-23  

hax你好，07年你提过ajax的Future模式，（原帖：http://hax.iteye.com/blog/85130），不知道现在实现了没有，或者能不能说说思路，国外有几个（step.js、flow.js etc.）是把函数作为参数传入一个容器然后解析，但是感觉还不如callback清晰，尤其是其他人还要用到。
更喜欢的方式是
a=get("a.txt");
set(a,"b.txt");

1 楼 勾三股四 2010-12-23  

这本书太神奇了！！！