最近看了国内某位前端工程师今年出版的新书，其中讨论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.
在上述所有这些“问题实践”中，最根本的源头其实就是所谓“通用原子类”，也就是类似我之前[url=http://hax.iteye.com/blog/497338]批评过的MetaCSS[/url]的做法。显然，“通用原子类”正好是HTML5规范里所说的描述呈现效果而不是描述内容的性质。这个问题这里不再赘述，可看我之前的[url=http://hax.iteye.com/blog/500015]评论[/url]。
这里要剖析的是另外几条。
首先说第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条。大量使用“通用原子类”的后果其实就是[b]习惯于[/b]退化到都是平级的单class规则定义，也就是classitis（多class症）。
注：其实就算用“通用原子类”或MetaCSS，让其回归为inline style的缩写形式这样一种本源，本来是有更好的方式来避免specifity问题的。你想到没有？
然后说一下第5条。margin是一个有用的特性，当然前提是使用者了解文本排版中margin的意义。这里作者却只是视其为麻烦。这其实只说明了一点，那就是作者不知道margin的用途，或者认为margin的用途是无聊的——比如只关心最终样式的呈现，而不管设计意图。
所以这里一个需要考虑的问题是，CSS的可维护性从哪里来的？如果所有HTML和CSS每次都是全部推倒重来（许多公司的改版大概就是这样的），那么去关心和维护设计意图确实是没用的。这里根本不存在“维护”。否则，如果我们认为设计会逐步演化和发展（并且与文档内容和结构具有一定的独立性），那么显然真正反映设计意图的CSS会更具有“可维护性”。
最后，剩下2条，关于开发者名字作为class前缀的做法，请读者自行考虑。
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.
在上述所有这些“问题实践”中，最根本的源头其实就是所谓“通用原子类”，也就是类似我之前[url=http://hax.iteye.com/blog/497338]批评过的MetaCSS[/url]的做法。显然，“通用原子类”正好是HTML5规范里所说的描述呈现效果而不是描述内容的性质。这个问题这里不再赘述，可看我之前的[url=http://hax.iteye.com/blog/500015]评论[/url]。
这里要剖析的是另外几条。
首先说第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条。大量使用“通用原子类”的后果其实就是[b]习惯于[/b]退化到都是平级的单class规则定义，也就是classitis（多class症）。
注：其实就算用“通用原子类”或MetaCSS，让其回归为inline style的缩写形式这样一种本源，本来是有更好的方式来避免specifity问题的。你想到没有？
然后说一下第5条。margin是一个有用的特性，当然前提是使用者了解文本排版中margin的意义。这里作者却只是视其为麻烦。这其实只说明了一点，那就是作者不知道margin的用途，或者认为margin的用途是无聊的——比如只关心最终样式的呈现，而不管设计意图。
所以这里一个需要考虑的问题是，CSS的可维护性从哪里来的？如果所有HTML和CSS每次都是全部推倒重来（许多公司的改版大概就是这样的），那么去关心和维护设计意图确实是没用的。这里根本不存在“维护”。否则，如果我们认为设计会逐步演化和发展（并且与文档内容和结构具有一定的独立性），那么显然真正反映设计意图的CSS会更具有“可维护性”。
最后，剩下2条，关于开发者名字作为class前缀的做法，请读者自行考虑。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
