<div class="box"><img src="http://pics.taobao.com/bao/album/promotion/taoscars_180×95_071112_sr.jpg" /></div>
发现很多朋友对 CSS 的优先权不甚了解，规则很简单。需要说明的一点，如果你的样式管理需要深层判断 CSS 的优先权，更应反思自己的 CSS 代码，是否合理？是否优化？
CSS2.1 中规定了关于 CSS 规则 Specificity（特异性）的计算方式，用一个四位的数字串（注：CSS2 中是用三位）来表示，最后以 Specificity 的高低判断 CSS 的优先权。
Specificity 具体的计算规则：
最后逐位相加数字串，得到最终的 Specificity 值，按照从左到右的顺序逐位比较。
除了 Specificity 还有一些其他规则：
范例分析：
最近对Web前端有很多想法，刚好看到这篇文章，跟我想法不谋而合，所以翻译出来与大家分享。许久没翻译了，里面多少还是有些我没能完全理解，意译过来，如果错误，请务必指出和修改，谢谢。
原文The Time is Now for Front-End Architects， 来自：Garrett Dimon，感谢作者的许可。
去年，我在YTS发表了前端架构师的想法，之后花更多时间来思考，现在更坚信这是一个不可或缺的角色。
当后端技术伴随.Net, Rails和Java之类的框架发展得越来越抽象和强大，前端技术的潜在发展也日益复杂。在束缚前端技术潜在好处的差劲实现之前， Web需要更多的前端架构师。
多亏了诸如跨浏览器支持的先进技术的发展，用户体验、更多有意义的主题比如无障碍都拨云见日，这个世界再也不仅仅就HTML和CSS如此简单，因此，绝大部分的团队都需要一个真正理解和实践涉及到前端的一切的人。
角色
这并不是一个扼要和简单的清单，对于下面的主题／技术，前端架构师也不能仅仅满足于了解一下里里外外而已，而是需要足够的深入研究，并有自己出色的见解。
作为一个前端架构师，必须拥有这些领域的绝对执行力。例如，前端架构师能够决定某个特性是使用AJAX还是传统的页面刷新。哪个更便于使用？对无障碍的影响如何？改用Flash有意义吗？
拨乱反正
表现，结构，行为和商业逻辑的混杂，导致不必要的复杂，导致难以维护的怪胎解决方案。就如后端需要正确地划分为数据层，商业逻辑，表现逻辑等，前端开发复杂到是时候调整其架构了。
编写良好结构或者说避免使用表格布局是远远不够的。这是第一步，前端架构的哆咧咪而已。现在是时候关注DOM脚本编程，AJAX, 无障碍等，该升级了。
非编程不可
我主张前端架构师必须懂得真正的编程知识，而这正是很多自封为前端架构师的人所缺乏的。我的意思不是能够剪切粘贴改进代码就行了，而是能够跟老练的工程师商讨如何能够最好地结合前端。
这就是说，前端架构师需要真正理解结构遭遇商业逻辑的问题。如果工程师说某些东西使用ASP.Net DataGrid是不可能实现的，前端架构师必须能够解释如何与为何要使用DataList或Repeater取代，解释为何DataGrid在该情景下是个错误的选择……
这只是个例子，问题还在于仅知道客户端编程也是不够的。能够使用与工程师相同的术语，能够讨论（前后端）关键集成的最佳解决方案，这是绝对必须的。
断线的风筝
我们今天正处在一个不妙的处境中，原因在于几乎没有人能够为前后端的沟壑搭桥。一般工程师不会有兴趣或实践标记，CSS, 或DOM脚本编程，大部分客户端开发者也没有与后端技术协作的经验。几周入门PHP不会成为程序员，几周入门XHTML也不会成为真正的客户端开发者。
罪魁祸首
我首先想到的十足例子是，ASP.Net完全漠视Web标准，同样地，web氛围（我们指表格和占位gif）让Web标准郁闷。企业项目的大多数框架输出的标记，即使使用1999年的标准来衡量，都是糟糕无比的。
如此巨大和“专业”的产品怎么能才够不忽视，按理说是整个项目最简单的方面？只有静态代码。理由是，基于技术的立场衡量产品，结构，CSS和其他客户端技术都是“事后诸葛亮”。表现逻辑，结构和行为混杂，压根无助于无障碍，Web标准，或者前端技术干净的分离。抬起你的头来，就在2006，这些都成受欢迎的惯例了。
总结
如果这个世界上姿态最鲜明的产品和项目都如此低劣的方式来处理事情，其他的还有什么好说？毫无疑问，我们需要前端架构师，而且就在昨天。
归结于归结，我们有一堆相互关联的技术，很少人能够埋头钻研它们之间的关系，这很不幸。正确做事的真正价值在于容易的维护和长期的适应性。虽然在关键时刻，有些方式更容易选择其他的方法和拼凑起另外的东西。对某些人来说，这可能是可接受的做事方式。但是，对我们大部分人来说，这是拙劣的抉择，也非常不专业。
我交给你去想了。我假设你把车交给技工修理，修好了时候，瞧瞧引擎罩内大量的输送管，我不知道你对技工作何感想？
现在对于 inline-block 属性运用的需求也越来越多，可惜依旧只有 Firefox3 beta、IE8 beta、Opera、Safari 支持 inline-block 属性（注：原来只有 Opera、Safari 支持），但 IE6、IE7 可以通过触发 hasLayout 来模拟，Firefox2 有-moz-inline-box 和 -moz-inline-stack 私有属性。
在实际应用中 -moz-inline-box 会存在元素间的对齐等问题，虽然 Firefox 还有一个私有属性-moz-box-align 来帮助解决对齐问题，但依旧难以预料问题多多，而相对来说 -moz-inline-stack 的表现更像 inline-block ，这点可以在 Firefox3 中测试出来。但 -moz-inline-stack 使用时也会有一个 bug ，如果一个 display:-moz-inline-stack; 的元素外层元素是 display:inline; 即会使 Firefox 中其包含的链接不可点，这个需要用 position:relative; 来解决。
最终模拟代码：
