再次提醒
通过阅读器看到我这篇文章的朋友，你订阅的feed（http://my.donews.com/htmlor/feed/）已经是老的了！
此blog空间已停止更新（换到了 blog.htmlor.com ），因此请把订阅地址换成 http://feeds.feedburner.com/htmlor/ 吧。
麻烦了！
搬家终于完成
经过几天的忙活，终于搬家成功！
从my donews的免费空间到dreamhost的付费主机，从wordpress到wordpress，代价几乎没有（文章连同评论全部转移成功），也换了自己的简短域名（blog.htmlor.com），而且内容方面完全自己作主…… 不管怎么说，自己是比较满意的。
由于原blog（http://my.donews.com/htmlor/）会停止更新，敬请订阅原feed（http://my.donews.com/htmlor/feed/）的朋友们更换订阅地址为 http://feeds.feedburner.com/htmlor/ 。麻烦了！
google收购wiki协作服务jotspot
google又出手了，这次被搞定的是jotspot，一个口碑与质量上佳的wiki协作服务。（请看官方声明与techcrunch介绍）
关于jotspot，我是有些了解的（在3个月前的一篇文章里就推荐过它）。不过由于不常用，往往是想起才光顾一次，每次都浮光掠影。这次重新登录，发现真是变化不小，无论界面还是功能都有了非常大的进步。
jotspot的服务分为两种：wikis for work和wikis for life。wikis for work是主营业务，提供企业级的一站式wiki协作服务。其针对企业内部使用、开发团队管理的程序种类繁多、应有尽有（包括项目管理、bug报告、邮件列表、待办事项、电子表格、知识库，以及相册、组日历、组联系人、blog、论坛、文件柜等），而且全部是“一点-安装”（one-click install），极为轻松方便。而wikis for life相对简单，包括家庭wiki和校友wiki两种。
google已经把writely招致麾下，与spreadsheets整合成了google docs & spreadsheets，此次收购jotspot，在项目管理方面再添一员猛将，其对于在线office市场真的是志在必得了。
架构css
大约一个月之前，看到了Garrett Dimon的这篇《Architecting CSS》，不禁动了翻过来的念头。联系作者后他满口答应，我也准备3天之内完工。只可惜国庆假期琐事繁多，一直腾不出手来开工。拖啊拖拖啊拖，一直到今天才得完成。这效率……唉，真是愧对作者，希望他别见怪~
废话不说了，回到主题。关于这篇文章，我有两个声明：1.不是css用法指南，而是宏观上的组织架构方法；2.没有提出绝对正确的某种方案，而是列出多种方案以及利弊让你根据具体情况选择。
全文如下：
架构css
作者：Garrett Dimon
翻译：htmlor
在当前浏览器普遍支持的前提下，css被我们赋予了前所未有的使命。然而依赖css越多，样式表文件就会变得越大越复杂。与此同时，文件维护和组织的考验也随之而来。
（曾几何时）只要一个css文件就够了——所有规则（rule）汇聚一堂，增删改都很方便——可这种日子早已远去。（现在）建立新网站时，必须花点时间好好筹划怎么组织和架构css。
文件的组织
构建css系统的第一步是大纲的拟定。（我认为）css组织规划的重要性堪比网站目录结构。（htmlor注：用词夸张一点，让你加深记忆） 没有哪种方案放之四海而皆准，因此我们会讨论一些基本的组织方案，以及它们各自的利弊。
主css文件
通常可以使用一个主css文件，来放置所有页面共享的规则。这个文件会包含默认的字体、链接、页眉和其他等样式。有了主css文件之后，我们开始探讨高级组织策略。
方法一：基于原型
最基本的策略是基于原型页面（archetype page）分离css文件。假如一个网站的首页、子页面和组合页设计不同，就可以采用基于原型的策略。（这种策略下）每个页面都会有专属的css文件。
在原型数量不多的情况下，这个方法简单明了、行之有效。然而，当页面元素并不按部就班的位于各个原型页时，问题就出现了。如果子页面和组合页共享某些元素，而首页却没有，我们应该怎么做呢？
- 把共享元素放入主css文件。这虽不是最纯正的解决办法，却适用于某些具体情况。可是如果网站庞大，（这样做的话）主css文件会迅速膨胀——这就违背了分离文件的初衷：避免导入不必要的大文件。
- 在组合页和子页面的css文件里各放一份样式代码。（这么做）就意味着要维护冗余代码，很显然我们不想这样。
- 创建一个新的文件，由这两种页面共享。这听起来不错。不过假如只有10行代码，我们创建这个文件仅仅是为了共享这10行代码？（htmlor注：杀鸡用牛刀？） 这方法很纯粹，但如果网站庞大有很多对页面共享很少量元素时（htmlor注：比如30对页面分别共享10行代码），就显得很笨重了。
- 创建一个单独的css文件，包含所有共享元素的样式。这方法可能比较简单，却要取决于网站的大小和共享元素的多少。有种情况会很烦：导入了一个很大的css文件，但页面只用到一小部分样式——还是那句话，这违背了分离文件的初衷。
这就是我所说的重叠的两难（overlap dilemma）。零碎css规则的重叠不一而足，并没有一个完全清晰无误的方案来组织它们。
方法二：基于页面元素/块
如果网站使用服务器端include，这个方法会很不错。举例说明，如果使用页眉include，它会有自己相应的css文件。页脚或者其他部分的include可以如法炮制，只须导入自己的css文件。这个方法简单干净，不过可能会产生很多小css文件。
举例来说，假如页脚的样式只需要20行css代码，单独创建一个文件就划不来了。而且这个方法会导致每个页面都包含一堆css文件——因为有多少include，就得有多少css文件。
方法三：基于标记
这个方案直观实际，与前一个类似。如果网站共有30个页面，其中10个含有form，那么可以创建一个css文件专门处理form的样式，只在这10个页面导入它。如果另外10个页面含有table，就创建一个文件专门处理table样式……诸如此类。
另外的组织技巧
除了用主观的方法组织文件，我们还要考虑如打印、手持设备和屏幕等多种媒体类型。这虽然已经很清楚的定义过，可依旧是建立文件结构时应该考虑的一个因素。一旦必须支持多种媒体类型，主css文件里的某些规则可能就得重新考虑。
另外，品牌联合也可能是一个重要因素。（htmlor注：如google和nike联手推出的joga） 如果涉及品牌联合，你就得考虑哪些元素应该调整以适应另一品牌。比如分别使用不同的css文件等。
还有一个常被忽略的技巧：使用嵌套的@import语句。只包含一连串@import语句，或者再加几句css规则，就能创建一个css文件。用这个方法完全可以创建网站的主css文件（用@import导入各部分的样式文件）。假如网站的每个页面都导入了4到5个不同的css文件，无疑你应该考虑使用这个技巧。
规则和选择器的组织
谈完了文件组织，接着讨论一下怎么组织文件里的东西吧。很自然，我们希望在文件里畅通无阻的浏览，迅速找到要编辑的选择器（selector）或规则。
冗余 vs. 附属
正如Dave Shea在其文章《冗余 vs. 附属》（Redundancy vs. Dependency）里所说的，你必须不断了解级联（cascade）。你要决定是对选择器编组（意味着附属），还是把它们分离（意味着冗余）。编组可以保持代码简洁扼要，可是会建立附属关系，导致维护开销增加。如果不编组，就会增加文件大小，让相似的选择器保持一致变得困难。只有做好这种权衡、取舍，才能每次都作出正确的决定。
按相互关系/上下文编组
既然文件组织可以是主观的，那么显然，按照规则和选择器与其他部分的相互关系来进行编组是最好的方法。举例说明，假设你用容器、页眉和页脚来完成布局，就应该把它们编成一组。
这似乎很简单，其实不然。比如，把页眉中的导航加入css时，是将它跟父元素编组还是独立编组？这种情况下，要视乎规则的上下文。通常，页眉与页面布局相关，应该与其他布局元素一起编组。而导航是页眉的一块，应该和页眉的其他块编组，而不是页眉本身。
使用注释
跟大多数代码类似，注释是组织良好与否的关键。应该根据css的控制范围，清楚的标注每节（section）。最好确保注释视觉突出，以便在内容滚动、一目十行时快速定位。
Doug Bowman在其文章《css组织技巧之一：标记》（CSS Organization Tip #1: Flags）里把css注释玩得高明之极。他详细说明了在节名之前加上等号，以便使用文本编辑器的查找功能迅速跳到某节。
别忘了
你应该细致认真的了解了特异性、级联和继承，并善用它们。它们之中的每一项都可以是你最可怕的敌人，也可以是你最友善的朋友。当建立庞大的网站时，是否理解这些细微精妙之处，决定了你所构建的是坚如磐石的系统，还是经不起风雨的豆腐渣工程。（htmlor注：这句完全意译，比较爽）
属性的组织
现在我们了解了文件的组织，也知道了文件内规则的组织，但还有一个重要的组织环节（没有提到），那就是属性（attribute）。虽然属性比前两个概念更简单，可是还有一些非常好的、能够保持规则整洁的方法很值得一提。
按字母排序
提到属性，如果说需要遵循什么原则的话，那就是：按-字-母-排-序。其实这招对于属性浏览帮助不大，不过可以防止属性值覆盖这种偶然事件的发生。
举个例子吧，已经数不清有多少次，我为某个选择器定义过了margin值，之后的某天无意间又加了一个（或前或后）。（这种情况下）后一个属性自然会起作用。假设不知道第二个属性存在，不管我怎么调整第一个属性值、刷新浏览器，也看不到页面变化。（htmlor注：这个问题我深有体会） 如果按照字母顺序排列，你就会发现margin被定义了两次（因为它们挨在一起），这个问题自然可以避免。
优先项
当网站复杂、牵涉太多css文件时，会建立大量的附属关系。一旦需要定制某个元素特有的样式，!important选项似乎是最佳选择。没错，!important是能解一时之需，但最好搞清楚导致问题的根源，然后根据级联关系决定是否真的需要用它。
如果你对上文提到的特异性、级联和继承很熟悉，大可不必抱着!important一颗树不放。（htmlor注：整片森林等着你~） 当然它还是会派上用场，不过使用之前要对具体情况了然于胸。千万不要因为不知问题的症结所在而把!important当作捷径或是补救方案。
小结
当我们变得依赖css而使样式表日渐复杂时，就需要正确的计划来避免犯错，并使代码易于维护。既然完美无缺的方案并不存在，那么了解css的工作方式以及文件、选择器和属性的多种组织方案，无疑有助于我们写出优质的代码，经受住时间考验。
（完）
关于博客实名制，他们如是说…
对于“博客实名制”这件事，blogger们众说纷纭（也差不多众口一词），有些话语颇有趣味，也深得我心。特摘选如下：
这是一个把黑格尔灭掉的逻辑。
有人说，你不干坏事，怕实名作甚？说这种话的，纯属猪头。这种人可能已经习惯了一天到晚有人盯梢，习惯了在自家做个爱都有摄像头监视着，习惯了腹诽几句领导都会被蛔虫给汇报了。
博客实名制像一个巨大的黑色梦魇突然降临比特世界，尽管这一天距离真正实现还有时日，但是我已经闻到了皮肤和毛发的焦味，那炙人的气息扑面而来。
博客实行实名制后，假如我还要写博，我该写些什么呢？纪念红军长征七十周年；纪念中华人民共和国成立五十七周年；安倍当选为联合国秘书长；台湾竞选相互拆台。
我只不过想在家里厕所小个便，难得还先要去居委会登订挂号，不然就是随地便溺不成？
——寻找树袋熊的桉树的《blog实名制,理由是—–不需要理由》
“深圳自从取消摩托车上路后，那些飞车抢夺的人就用到汽车了”……
我感觉信息产业部的人把实名当做时尚了。
用实名制让大家主动配合GFW，再加上备案，这个社会就和谐了嘛。
这玩意，吐啊吐啊也就习惯了。
我可能还会跑到国外BSP那里“开博”。已经想好，在那些地界上，我的blog要起名叫作keso乱弹琴，老白真说胡话，或者叫刘韧123，叫dodonews。
firefox 2正式版官方发布
在3次预览版接连发布、吊足了人们胃口之后，正主儿终于“千呼万唤始出来”。为了这次发布，mozilla.com连网站都改版了，变得更加简洁、大气。
在ie 7面世之后发布，firefox 2应该是打算知己知彼、后发制人。至于能不能达到目的，集万千宠爱于一身，就得用户说了算了。
啥也不说了 准备搬家吧
巴西站 舒马赫捍卫尊严的绝唱
f1最后一站巴西站结束了，舒马赫和法拉利没能创造奇迹。其实上一站日本战比赛过后，这个结果已经在大家的预料之中了。
舒米从第10位发车，途中发生爆胎一度跌到18位，但他之后一路狂奔，经过12次超车，最终追到第4位。赛程最后阶段的两次堪称教科书式的超车，令人热血沸腾、如痴如醉。舒米先是一个假动作骗得费斯切拉冲上草地，顺利超越，之后又凭借经验与胆识硬吃下赛季顶替自己位置的莱科宁，电光石火间超车成功。他是在用毕生的赛车经验，为大家奉献一曲绝唱，即使不能获胜不能赢得总冠军，也要捍卫自己的尊严！
这站比赛有3个主角：菲利普·马萨，13年来第一个夺得巴西站冠军的巴西人；费尔南多·阿隆索，成功卫冕的年度车手总冠军；迈克尔·舒马赫，将要退役的七冠车王。舒米孤独的背影，在兴高采烈的马萨和阿隆索相形之下显得有些凄凉、有些悲壮，但在我眼中，他才是主角中的主角，王者中的王者！当前无古人（很可能也后无来者）的他选择退出，一个时代结束了。
我对f1的关注，因舒米而起，也该因舒米而终。之后的f1比赛，应该不会怎么看了。