上一篇blog中我提到了“国内某位前端工程师今年出版的新书”，这里我想就这本书多说几句。
这本书的总体质量，当然肯定比《XX征途》要强。不过仍然出现了一些匪夷所思的bug。譬如说该书的第一章第一节，作者举了一个“糟糕的老网页的实现”的例子，并指出这个页面代码的问题如下：
* div布局和table布局混用；
* 标签名有大写，也有小写；
* 样式组织混乱，有用<style>标签的，有用<link>的，也有直接写在标签内的；
* JavaScript的编码风格很不一致；
……（还有好几条，这里略过）
先不论这几条是否一定“不利于维护”，我扫了一下那个“糟糕的老网页的实现”，却惊异的发现：
1. 该网页根本就是全部使用table来进行布局，并没有用CSS布局。当然，这个网页里有用css，但是并没有一句css是用来进行layout的。除非作者所说的“div布局”并非是我理解的CSS布局，而是把”<div align="center">“称作”div布局“。
2. 该网页里的所有标签明明都是小写！为了确定这点，我还看了好几遍，我还找其他人也看了好几遍，最后确定我没看错，所有标签都是小写。
3. 该网页里根本没有<link>标签。同样的，为了确定这点，我看了好几遍，还找其他人也看了好几遍。
4. 该网页里只有1个外部js文件的引用，2句inline的handler代码（分别是onmouseover="this.focus()"和onfocus="this.select()"），2行js代码（内容是“UserTrack.init(...)和document.form1.wd.focus()”）。不知道作者是如何从中看出“JavaScript编码风格”的。
上述几条，都是属于不用动脑即能发现的问题，有些（比如大小写）甚至都不需要懂技术就能看出来。这还是全书的第一章第一节！对此我最善意的猜测是，这个第一章或许是接近出版时临时草就补上的。即使如此，无论作者或是编辑，对此都负有不可推卸的责任。就是写篇blog，也不会有这样离谱吧？
其实，因为这本书定位的读者群是有一定经验的Web前端开发者，所以对于类似这样的问题，姑且认为不是像写给初学者的书那样重要。但是仍旧要拿出来说。因为这是一个态度问题。这里有出版社的问题，有作者的问题，有编辑的问题，还有那些写“推荐”的人的问题――你们写推荐的时候到底仔细看过没有？如果你没看过，那么你凭什么推荐？如果你看过的话，为什么那么明显的bug也没有发现呢？
所以没错，我又要“兼批技术社区的吹捧之风”了。
首先此书有一位国内重量级的前端开发者为其写推荐序（比起给《xx征途》写推荐的月影和winter，名声可能更大）。不过有趣的是，这篇序写得很艺术，提到了该书的目标与其他书“有本质的区别”，提到了该书前两章讨论的内容“很有必要”，提到了“本书中包含着许多开发的思想和经验”……却没有直接对该书进行褒扬。序的最后一句是“不同水平的Web前端工程师都会从中获得启发。”他的这句话非常“正确”，因为即使像我这样，对于其中的“许多开发思想和经验“持否定态度，却也不能否认确实“获得了启发”，呵呵。
相比而言，若干公司的前端部门的大小经理的“赞誉”，就比较赤裸裸了。另外还有若干技术社区的“赞誉”（注意是社区而不是社区的某人）。我纳闷的是，这些社区推荐中，推荐语都是“谁”写的？这个“谁”为什么就能代表整个社区对一本书进行“赞誉”？
回到这个书本身，既然是一本关于最佳实践的进阶书，重点其实在于它所推荐的方法。不幸的是，占据该书1/3篇幅的CSS部分，其中核心的几条理念几乎都是站不住脚的（其他部分其实也有一些问题，但是不像CSS那样严重）。当然，这类我称之为Anti-Pattern实践和理念并非凭空产生，而确实是有原因的，是我们需要面对的问题，我们既往在这方面的讨论确实很不够。下一篇blog我想就这个再做点讨论。
1 楼
lifesinger
2010-12-23
看来 hax 比较空闲啊，书看了也就罢了，居然看完还有时间评，哈哈
国内前端，没什么深度，就如 D2 一样，大家平时都很寂寞，找个机会凑合一块，取取暖，图个热闹而已
国内前端，没什么深度，就如 D2 一样，大家平时都很寂寞，找个机会凑合一块，取取暖，图个热闹而已
2 楼
hax
2010-12-23
@玉伯 这本书我从裕波（你们两个名字差不多撒）那里拿来放在案头好久了，但是一直没有空看，一直到去D2的路上，在火车上打发时间，我才拿出来看，然后在同行的老赵、winter、裕波等的“鼓励”下，俺在看书的时候也写了些批注。所以这两篇书评其实只是捡了几点整理上来。BTW，我觉得这次D2还是有些让我很振奋的分享的，如讲CommonJS的那个，讲lofn的90后，当然还有老赵（只是我之前已经听过了）。还有待会儿俺写一篇关于你的kissy演讲里的一些想法，哈哈。
3 楼
zhouyrt
2010-12-24
呵呵，是不是裕波/玉伯的书出了你也要谈谈？
4 楼
lifesinger
2010-12-24
@hax: 期待对 kissy 的评论，尖锐一点，我喜欢直白
话说我那本书的大纲，编辑曾给你看过。等第一部分写完，再发给 hax 看下，到时可别说没时间
话说我那本书的大纲，编辑曾给你看过。等第一部分写完，再发给 hax 看下，到时可别说没时间
5 楼
trydofor
2010-12-24
1） 学院派的造论文。
2） 技术圈的乱出书。
非名则利，贻害万年。
需要更多的'方舟子'
2） 技术圈的乱出书。
非名则利，贻害万年。
需要更多的'方舟子'
6 楼
fujohnwang
2010-12-24
不忽悠咋卖？
7 楼
wjywjy678
2010-12-24
不写本书，哪来的职称
8 楼
cly84920
2010-12-26
谢谢hax的提醒，也谢谢你的不点名。我就是hax文中所指“国内某位前端工程师”。关于“糟糕的老网页的实现”的确是因为一些原因疏忽了。本来我是贴了hao123的一个网页的代码在这里的，但因为实在太占篇幅了，而这些代码其实只是为了给个反例，读者并不会过于关心，所以为了不分散注意力，把代码删了很大一部分出去，最后造成了“很多提到的问题在代码中找不到”的局面。这是我的疏忽，对不起各位了。
至于“什么样的实践可以带来好的可维护性”，这是个见仁见智的问题，就像不同工程师编写代码时喜好不同的风格一样。实际工作中，很多时候技术上的完美是无法实现或者成本高昂的，比如说，用不用所谓“css原子类”就是个这样的问题，我也明白css原子类其实是标签内置样式的一个变形，该不该这么去用我也曾纠结过。但过于追求理论上的完美容易变成学院派的老学究，我倾向于“理论是为实践而服务的”。
“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.”
我明白标准在提倡什么样的思路，但。。。就像很多人都提到过的，不要用xx1,xx2,xx3来命名一样， 我一直很难做到，就像很多人说TDD很重要，我一样很难做到，就像很多人提倡“对修改封闭对新增开放”一样，很多时候我也做不到。《code at works》里我看了两位大师的采访，其中一位完全不做“TDD”，甚至认为设计模式就是胡说八道，我并不认同他的观点，但他的话让我意识到“理论只是种推荐，实践才是王道，要有怀疑精神”。理论上是提倡的东西，在实践起来的时候，努力向其靠拢就行，不必过于较真。如果追求理论，在实践中遇到困难，我会优先实践，轻理论。
我书里用到的方法，全是我自己在实际工作中积攒下来的经验，它们很好地帮助了我，虽然我明白它不是那么完美，但它成了我的风格，能够帮助我解决实际工作中遇到的各种问题。暂时我还没有找到更佳的实践方式，能够在不影响可维护性的情况下向理论靠拢。
前些日子，我在看马丁的《clean code》，书里序言表达了这样的意思我印象非常深刻“不同的人可能喜欢不同的风格，这本书讲的是我的流派”。不敢跟马丁大师相提并论，仅借大师的话表达相同的想法。在我的书的前言里，我说“技术非黑即白，只有对和错，而技巧则见仁见智。本书是笔者个人的经验分享，尽信书不如无书，大家可以有选择地吸收，如果对书中的观点或技巧有不同的见解，非常欢迎与笔者交流”。《code at works》里采访Zawinski时有如下对话，我深以为然，而且这也改变了我看待别人编码风格的角度。
“
Seibel：你有过相反的感觉吗，觉得身边的计算机科学家并不像自己那样懂得编程的真谛？
Zawinski：我经常有那种感觉，不过，“哇，你们这些家伙搞错对象了。”这种想法其实并不多，更多是觉得：“哇，我们只是兴趣不同。”
”
兴趣不同，看待相同问题会有不同的取舍。
写这本书，我的目标用户其实主要是“有经验，但没风格的工程师”。我并不希望本书会让每个人都说“这就是对的”。对还没有自己成熟风格的工程师来说，我的书可以给他们一个相对完善的思路。而对于已经有自己风格的工程师来说，我希望他看到我的书时，会说“这种思路是我之前没想过的，恩，原来还可以这么考虑问题啊”。克军说的“不同水平的Web前端工程师都会从中获得启发”，我想他指的应该也是这个意思，关于这点，hax你自己不也承认了吗？
最后，借这里跟各位帮我写推荐的童鞋们道歉了，给你们添麻烦了。
至于“什么样的实践可以带来好的可维护性”，这是个见仁见智的问题，就像不同工程师编写代码时喜好不同的风格一样。实际工作中，很多时候技术上的完美是无法实现或者成本高昂的，比如说，用不用所谓“css原子类”就是个这样的问题，我也明白css原子类其实是标签内置样式的一个变形，该不该这么去用我也曾纠结过。但过于追求理论上的完美容易变成学院派的老学究，我倾向于“理论是为实践而服务的”。
“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.”
我明白标准在提倡什么样的思路，但。。。就像很多人都提到过的，不要用xx1,xx2,xx3来命名一样， 我一直很难做到，就像很多人说TDD很重要，我一样很难做到，就像很多人提倡“对修改封闭对新增开放”一样，很多时候我也做不到。《code at works》里我看了两位大师的采访，其中一位完全不做“TDD”，甚至认为设计模式就是胡说八道，我并不认同他的观点，但他的话让我意识到“理论只是种推荐，实践才是王道，要有怀疑精神”。理论上是提倡的东西，在实践起来的时候，努力向其靠拢就行，不必过于较真。如果追求理论，在实践中遇到困难，我会优先实践，轻理论。
我书里用到的方法，全是我自己在实际工作中积攒下来的经验，它们很好地帮助了我，虽然我明白它不是那么完美，但它成了我的风格，能够帮助我解决实际工作中遇到的各种问题。暂时我还没有找到更佳的实践方式，能够在不影响可维护性的情况下向理论靠拢。
前些日子，我在看马丁的《clean code》，书里序言表达了这样的意思我印象非常深刻“不同的人可能喜欢不同的风格，这本书讲的是我的流派”。不敢跟马丁大师相提并论，仅借大师的话表达相同的想法。在我的书的前言里，我说“技术非黑即白，只有对和错，而技巧则见仁见智。本书是笔者个人的经验分享，尽信书不如无书，大家可以有选择地吸收，如果对书中的观点或技巧有不同的见解，非常欢迎与笔者交流”。《code at works》里采访Zawinski时有如下对话，我深以为然，而且这也改变了我看待别人编码风格的角度。
“
Seibel：你有过相反的感觉吗，觉得身边的计算机科学家并不像自己那样懂得编程的真谛？
Zawinski：我经常有那种感觉，不过，“哇，你们这些家伙搞错对象了。”这种想法其实并不多，更多是觉得：“哇，我们只是兴趣不同。”
”
兴趣不同，看待相同问题会有不同的取舍。
写这本书，我的目标用户其实主要是“有经验，但没风格的工程师”。我并不希望本书会让每个人都说“这就是对的”。对还没有自己成熟风格的工程师来说，我的书可以给他们一个相对完善的思路。而对于已经有自己风格的工程师来说，我希望他看到我的书时，会说“这种思路是我之前没想过的，恩，原来还可以这么考虑问题啊”。克军说的“不同水平的Web前端工程师都会从中获得启发”，我想他指的应该也是这个意思，关于这点，hax你自己不也承认了吗？
最后，借这里跟各位帮我写推荐的童鞋们道歉了，给你们添麻烦了。
9 楼
hax
2010-12-27
@cly84920
没想到那么快就传播到你那里了，呵呵。昨天的Web标准化交流会（上海站）的活动上，我也被逼小小谈了一下这个话题。
我想有机会的话，可以当面再讨论一下这个话题。这里简单的谈两点想法：
首先，我认为这种实践确实是有原因的，而且在某些场合是能提高效率的――但是我不认为那是可维护性。我要强调的是，CSS是设计工具，CSS的可维护性实际上要考虑的是“设计的可维护性”，而不是敲代码的效率。现在前端开发者不像以前大多从美工而来，有许多是以编程为主的“前端工程师”，这本是好事，但是也出现了问题，就是滑向了“攻城师”思维，而逐渐忽视了对设计的理解。
本次D2也是一个例子，D2本来的含义是Designer和Developer，但是这次全部是开发方面的主题，设计主题一个也没有了！
正因为开发者逐渐失去了对设计的关照，而将全部精力集中于代码上，CSS的一些与设计密切相关的特性被忽视甚至反对了。比如，追求所谓“selector优化”，即写尽量简单的selector来“提高性能”。又如你书中提出的尽量降低selector的specificity。这些都是忘记了CSS的本质。
其次，就这种实践本身而言，也有可改进的地方（虽然我不赞同推广这种实践）。比如很简单的一点，原子类的样式可以是!important的。
有机会聊吧。
没想到那么快就传播到你那里了，呵呵。昨天的Web标准化交流会（上海站）的活动上，我也被逼小小谈了一下这个话题。
我想有机会的话，可以当面再讨论一下这个话题。这里简单的谈两点想法：
首先，我认为这种实践确实是有原因的，而且在某些场合是能提高效率的――但是我不认为那是可维护性。我要强调的是，CSS是设计工具，CSS的可维护性实际上要考虑的是“设计的可维护性”，而不是敲代码的效率。现在前端开发者不像以前大多从美工而来，有许多是以编程为主的“前端工程师”，这本是好事，但是也出现了问题，就是滑向了“攻城师”思维，而逐渐忽视了对设计的理解。
本次D2也是一个例子，D2本来的含义是Designer和Developer，但是这次全部是开发方面的主题，设计主题一个也没有了！
正因为开发者逐渐失去了对设计的关照，而将全部精力集中于代码上，CSS的一些与设计密切相关的特性被忽视甚至反对了。比如，追求所谓“selector优化”，即写尽量简单的selector来“提高性能”。又如你书中提出的尽量降低selector的specificity。这些都是忘记了CSS的本质。
其次，就这种实践本身而言，也有可改进的地方（虽然我不赞同推广这种实践）。比如很简单的一点，原子类的样式可以是!important的。
有机会聊吧。
10 楼
cly84920
2010-12-27
这里有个问题是技术的“初衷”和“实践”。“初衷”是技术被创做时，由其“创作者”去考虑的，他会考虑一些问题，并做出一些取舍。值得注意的是，“创作者”的初衷一定是好的，但他也一定会遗漏一些盲点没有考虑到。“初衷”有他的闪光点，但在“实践”的时候遇到和“初衷”相冲突的时候怎么办？我个人认为必须意识到一个问题――初衷不可能完美。“初衷”和“实践”冲突的时候，死守初衷就过于教条主义了，技术是死的，而且是不完美的，人是活的。
“初衷”应该是一个“永远都不可能完美”的东西，他会不断地变化、完善。谁来驱动它的完善？“实践”。就像innerHTML属性，起初是微软的创新，“初衷”里没有它，但后来成了事实标准，就像getElementsByClassName，起初js的“初衷”里没有它，但现在html5里也得到了支持,就像jQuery的选择器，“初衷”里没有它，但现在也有了querySelector。html5不也说，“起初html不支持<a><div></div></a>，但很多人喜欢这么用，实践需要它，所以我们顺应工程师们的需要，html5支持<a><div></div></a>了”。“初衷”需要“实践”去发现问题，并不断完善，你说呢？
“
CSS的一些与设计密切相关的特性被忽视甚至反对了。比如，追求所谓“selector优化”，即写尽量简单的selector来“提高性能”。
”
对此，我的理解是css的设计初衷是提供样式的控制，它想了很多问题，但也忽略了一些问题，对于忽略的问题，有些人提出了意见。这些意见如果的确有道理，那就是“初衷”的疏漏。“初衷”并非不可挑战的。
"本次D2也是一个例子，D2本来的含义是Designer和Developer，但是这次全部是开发方面的主题，设计主题一个也没有了！"
这个问题我的理解是，D2的“初衷”是“Designer和Developer”，但经过举办几届D2的“实践”来看，基本上感兴趣的绝大部分是Developer，所以D2的含意索性就顺势改了，这次的主题不是叫“D的平方”吗？
“初衷”总是好的，但如何发展是需要灵活变化的，很多事的发展都和“初衷”完全不同。用更变化一点的眼光去看问题，可能适应得更好,你觉得呢？
相同的问题，不同的角度去看，会有不同的解决方案。很期待以你的角度去看，你形成的风格是怎样的。有空聊。
“初衷”应该是一个“永远都不可能完美”的东西，他会不断地变化、完善。谁来驱动它的完善？“实践”。就像innerHTML属性，起初是微软的创新，“初衷”里没有它，但后来成了事实标准，就像getElementsByClassName，起初js的“初衷”里没有它，但现在html5里也得到了支持,就像jQuery的选择器，“初衷”里没有它，但现在也有了querySelector。html5不也说，“起初html不支持<a><div></div></a>，但很多人喜欢这么用，实践需要它，所以我们顺应工程师们的需要，html5支持<a><div></div></a>了”。“初衷”需要“实践”去发现问题，并不断完善，你说呢？
“
CSS的一些与设计密切相关的特性被忽视甚至反对了。比如，追求所谓“selector优化”，即写尽量简单的selector来“提高性能”。
”
对此，我的理解是css的设计初衷是提供样式的控制，它想了很多问题，但也忽略了一些问题，对于忽略的问题，有些人提出了意见。这些意见如果的确有道理，那就是“初衷”的疏漏。“初衷”并非不可挑战的。
"本次D2也是一个例子，D2本来的含义是Designer和Developer，但是这次全部是开发方面的主题，设计主题一个也没有了！"
这个问题我的理解是，D2的“初衷”是“Designer和Developer”，但经过举办几届D2的“实践”来看，基本上感兴趣的绝大部分是Developer，所以D2的含意索性就顺势改了，这次的主题不是叫“D的平方”吗？
“初衷”总是好的，但如何发展是需要灵活变化的，很多事的发展都和“初衷”完全不同。用更变化一点的眼光去看问题，可能适应得更好,你觉得呢？
相同的问题，不同的角度去看，会有不同的解决方案。很期待以你的角度去看，你形成的风格是怎样的。有空聊。
11 楼
listenpro
2010-12-27
我是这本书序的作者。我认同hax对本书勘误部分的分析。但我认为这些只是瑕疵。这本书的意义是传播一种正确的开发思想。市面上各种教学书很多，但搞前端的都清楚，思路的重要性。所以，国内各种交流分享的意义也在于此。这本书弥补了在原创技术书上的空白。
说实话，写本书没多少稿酬，而投入的精力是巨大的。我跟作者说过写书的风险，但他是一个爱看书的人，他希望把他多年有价值的工作经验用书的形式总结下来。我感动于他的执着。国内的前端行业需要如此的执着。“有本质的区别”话外有很多意思。我不看技术书的原因是，国内的技术书都很垃圾，都是堆砌，都是没有实践支撑，这本书至少够诚恳。
@lifesinger, 我丝毫不认为这本书很”浅“。所谓很深的不过故弄玄虚，像D2上老赵的jscex和lofn不过是玩语言的自娱自乐，不要误入歧途。
trydofor的名利说不成立。图名图利就翻译了，原创多费劲啊。“学院派”更不成立，前端技术还没成熟到那种程度。
说实话，写本书没多少稿酬，而投入的精力是巨大的。我跟作者说过写书的风险，但他是一个爱看书的人，他希望把他多年有价值的工作经验用书的形式总结下来。我感动于他的执着。国内的前端行业需要如此的执着。“有本质的区别”话外有很多意思。我不看技术书的原因是，国内的技术书都很垃圾，都是堆砌，都是没有实践支撑，这本书至少够诚恳。
@lifesinger, 我丝毫不认为这本书很”浅“。所谓很深的不过故弄玄虚，像D2上老赵的jscex和lofn不过是玩语言的自娱自乐，不要误入歧途。
trydofor的名利说不成立。图名图利就翻译了，原创多费劲啊。“学院派”更不成立，前端技术还没成熟到那种程度。
12 楼
trydofor
2010-12-27
引用
trydofor的名利说不成立。图名图利就翻译了，原创多费劲啊。“学院派”更不成立，前端技术还没成熟到那种程度。
好吧，言重了。真没看这书，泛泛贬了下，没针对具体。
看官酌情理解，作者量力出书。
13 楼
faceach
2010-12-27
认同hax的见解，前端开发者应该是一个需要拥有设计感的完美主义者。
从 “通用原子类” 来看，我觉得它对于实践开发时有益的，提高开发效率而且可以全局引用，但是需要定义得更精简，作者的 “通用原子类” 太大，就增加了维护的代价。
从 “通用原子类” 来看，我觉得它对于实践开发时有益的，提高开发效率而且可以全局引用，但是需要定义得更精简，作者的 “通用原子类” 太大，就增加了维护的代价。
14 楼
hax
2010-12-28
难得那么热闹啊。
@cly84920
你说的实践去完善肯定是正确的。但是不能空泛的孤立的谈。比如，HTML5吸取了过去的许多教训，但是在最主要的大政方针上，如语义，其实并没有改变，相反是增强了。
关于class属性的解说，你可以对照HTML4，可以发现HTML4其实是有些含糊的，它提及了class可以作为样式的钩子，也就是说从HTML4标准本身并不能得出不能写“原子类”，反而是HTML5明确了class的推荐用法。
并不是说HTML5就一定是不可质疑的，但是HTML5作为基于过往Web实践的经验对标准进行重新梳理，其对标准的改进，可以被认为是整个Web开发社区的共识。如果我们自己有什么“最佳实践”是反其道而行的，我觉得首先要检讨一下自己。
再说CSS，CSS确实有不少问题，最主要的大概是这几个：
1. 浏览器对高级selector的支持太差（可怜的IE6）
2. CSS布局能力不够，CSS3的高级布局特性在浏览器上的实现速度太迟缓了
3. CSS没有内置样式复用机制（这不是疏忽，而是有意为之的）
但是同样的，到现在为止，我没有看到对CSS的核心设计本身有什么批评。CSS的核心设计其实是非常棒的。我曾做过一段时间的WinForm开发，传统的GUI编程对样式的处理，和CSS比起来，简直是一坨屎。相信许多做过Web开发的人回去做Desktop的GUI开发都有同感。所以新的平台基本上都在借鉴（如XAML）甚至直接引入CSS（如Flex、JavaFX）。
因此，我一直认为，在挑战“初衷”之前，应该先弄明白“初衷”。
@listenpro
欢迎来凑热闹，呵呵！
写书风险大，但是也不能否认出书带来的好处。
抛开这些不谈，至少有一点，技术书，光“诚恳“是不够的。如果是诚恳的传播了一种”不那么正确的开发思想“呢？比如我就没在douban的源码中看到过用”原子类“。
所以我觉得你是不是对cly84920同学的要求放得太低了？我们不能把他写的书和”堆砌出来的垃圾书“（比如css8之流9个月出9本书的那种）去比，那标准也太低了。
此外，我认为你说”老赵的jscex和lofn不过是玩语言的自娱自乐“太偏颇了，也许是在D2上老赵和90后小朋友的时间不够，所以你没有完整的理解他们讲的东西的意义。目前而言，无论是jscex还是lofn仍然处于实验室阶段，但是这种思路在本次D2上集中体现，不是没有原因的。随着开发的复杂度提升，JS的一些弱点越来越暴露出来，这些不是单靠更好的库或框架可以解决，我们需要语言级别的增强。Hedger讲的Closure Compiler，正是一个非常好的例子。我个人甚至希望能在明年的D2上看到这个方向上能有成熟的产品，即从语言层面到框架和库到部署的完整解决方案。
@cly84920
你说的实践去完善肯定是正确的。但是不能空泛的孤立的谈。比如，HTML5吸取了过去的许多教训，但是在最主要的大政方针上，如语义，其实并没有改变，相反是增强了。
关于class属性的解说，你可以对照HTML4，可以发现HTML4其实是有些含糊的，它提及了class可以作为样式的钩子，也就是说从HTML4标准本身并不能得出不能写“原子类”，反而是HTML5明确了class的推荐用法。
并不是说HTML5就一定是不可质疑的，但是HTML5作为基于过往Web实践的经验对标准进行重新梳理，其对标准的改进，可以被认为是整个Web开发社区的共识。如果我们自己有什么“最佳实践”是反其道而行的，我觉得首先要检讨一下自己。
再说CSS，CSS确实有不少问题，最主要的大概是这几个：
1. 浏览器对高级selector的支持太差（可怜的IE6）
2. CSS布局能力不够，CSS3的高级布局特性在浏览器上的实现速度太迟缓了
3. CSS没有内置样式复用机制（这不是疏忽，而是有意为之的）
但是同样的，到现在为止，我没有看到对CSS的核心设计本身有什么批评。CSS的核心设计其实是非常棒的。我曾做过一段时间的WinForm开发，传统的GUI编程对样式的处理，和CSS比起来，简直是一坨屎。相信许多做过Web开发的人回去做Desktop的GUI开发都有同感。所以新的平台基本上都在借鉴（如XAML）甚至直接引入CSS（如Flex、JavaFX）。
因此，我一直认为，在挑战“初衷”之前，应该先弄明白“初衷”。
@listenpro
欢迎来凑热闹，呵呵！
写书风险大，但是也不能否认出书带来的好处。
抛开这些不谈，至少有一点，技术书，光“诚恳“是不够的。如果是诚恳的传播了一种”不那么正确的开发思想“呢？比如我就没在douban的源码中看到过用”原子类“。
所以我觉得你是不是对cly84920同学的要求放得太低了？我们不能把他写的书和”堆砌出来的垃圾书“（比如css8之流9个月出9本书的那种）去比，那标准也太低了。
此外，我认为你说”老赵的jscex和lofn不过是玩语言的自娱自乐“太偏颇了，也许是在D2上老赵和90后小朋友的时间不够，所以你没有完整的理解他们讲的东西的意义。目前而言，无论是jscex还是lofn仍然处于实验室阶段，但是这种思路在本次D2上集中体现，不是没有原因的。随着开发的复杂度提升，JS的一些弱点越来越暴露出来，这些不是单靠更好的库或框架可以解决，我们需要语言级别的增强。Hedger讲的Closure Compiler，正是一个非常好的例子。我个人甚至希望能在明年的D2上看到这个方向上能有成熟的产品，即从语言层面到框架和库到部署的完整解决方案。
15 楼
cuikai
2011-01-05
是够热闹的，为了能插上话，我先买一本看看去…………
16 楼
kyfxbl
2011-01-22
很好啊，作者很谦虚，而且实际上水平也很好。
看书其实也就是各得其所，溢美之词不能全当真，批评的意见也要有选择的吸收。
看书其实也就是各得其所，溢美之词不能全当真，批评的意见也要有选择的吸收。
17 楼
lispython
2011-02-03
@lifesinger 呼唤玉伯同学第一部分哦