此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又出手了，这次被搞定的是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市场真的是志在必得了。

废话不说了，回到主题。关于这篇文章，我有两个声明：1.不是css用法指南，而是宏观上的组织架构方法；2.没有提出绝对正确的某种方案，而是列出多种方案以及利弊让你根据具体情况选择。

全文如下：

架构css

作者：Garrett Dimon
翻译：htmlor

在当前浏览器普遍支持的前提下，css被我们赋予了前所未有的使命。然而依赖css越多，样式表文件就会变得越大越复杂。与此同时，文件维护和组织的考验也随之而来。

（曾几何时）只要一个css文件就够了——所有规则（rule）汇聚一堂，增删改都很方便——可这种日子早已远去。（现在）建立新网站时，必须花点时间好好筹划怎么组织和架构css。

文件的组织

构建css系统的第一步是大纲的拟定。（我认为）css组织规划的重要性堪比网站目录结构。（htmlor注：用词夸张一点，让你加深记忆） 没有哪种方案放之四海而皆准，因此我们会讨论一些基本的组织方案，以及它们各自的利弊。

主css文件

通常可以使用一个主css文件，来放置所有页面共享的规则。这个文件会包含默认的字体、链接、页眉和其他等样式。有了主css文件之后，我们开始探讨高级组织策略。

方法一：基于原型

最基本的策略是基于原型页面（archetype page）分离css文件。假如一个网站的首页、子页面和组合页设计不同，就可以采用基于原型的策略。（这种策略下）每个页面都会有专属的css文件。

在原型数量不多的情况下，这个方法简单明了、行之有效。然而，当页面元素并不按部就班的位于各个原型页时，问题就出现了。如果子页面和组合页共享某些元素，而首页却没有，我们应该怎么做呢？

1. 把共享元素放入主css文件。这虽不是最纯正的解决办法，却适用于某些具体情况。可是如果网站庞大，（这样做的话）主css文件会迅速膨胀——这就违背了分离文件的初衷：避免导入不必要的大文件。
2. 在组合页和子页面的css文件里各放一份样式代码。（这么做）就意味着要维护冗余代码，很显然我们不想这样。
3. 创建一个新的文件，由这两种页面共享。这听起来不错。不过假如只有10行代码，我们创建这个文件仅仅是为了共享这10行代码？（htmlor注：杀鸡用牛刀？） 这方法很纯粹，但如果网站庞大有很多对页面共享很少量元素时（htmlor注：比如30对页面分别共享10行代码），就显得很笨重了。
4. 创建一个单独的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的工作方式以及文件、选择器和属性的多种组织方案，无疑有助于我们写出优质的代码，经受住时间考验。

（完）

注：发现digg推荐的内容从来没变过。

这是一个把黑格尔灭掉的逻辑。

——带三个表的《博客实名制的悖论》

有人说，你不干坏事，怕实名作甚？说这种话的，纯属猪头。这种人可能已经习惯了一天到晚有人盯梢，习惯了在自家做个爱都有摄像头监视着，习惯了腹诽几句领导都会被蛔虫给汇报了。

——keso的《实名这档子事》

博客实名制像一个巨大的黑色梦魇突然降临比特世界，尽管这一天距离真正实现还有时日，但是我已经闻到了皮肤和毛发的焦味，那炙人的气息扑面而来。

——槽边往事的《鲁爷，我不想你》

博客实行实名制后，假如我还要写博，我该写些什么呢？纪念红军长征七十周年；纪念中华人民共和国成立五十七周年；安倍当选为联合国秘书长；台湾竞选相互拆台。

——花样年华的《假如博客实行实名制》

我只不过想在家里厕所小个便，难得还先要去居委会登订挂号，不然就是随地便溺不成？

——寻找树袋熊的桉树的《blog实名制,理由是—–不需要理由》

“深圳自从取消摩托车上路后，那些飞车抢夺的人就用到汽车了”……

——pipilu的《博客实名制》

我感觉信息产业部的人把实名当做时尚了。

——北辰的《同志们~窝心的继续博客吧》

用实名制让大家主动配合GFW，再加上备案，这个社会就和谐了嘛。

——滞销书的《实名制》

这玩意，吐啊吐啊也就习惯了。

——青睐的《让实名来得更猛烈些吧！》

我可能还会跑到国外BSP那里“开博”。已经想好，在那些地界上，我的blog要起名叫作keso乱弹琴，老白真说胡话，或者叫刘韧123，叫dodonews。

——keepwalking的《正在准备起诉donews》

在3次预览版接连发布、吊足了人们胃口之后，正主儿终于“千呼万唤始出来”。为了这次发布，mozilla.com连网站都改版了，变得更加简洁、大气。

在ie 7面世之后发布，firefox 2应该是打算知己知彼、后发制人。至于能不能达到目的，集万千宠爱于一身，就得用户说了算了。

虽然很喜欢wordpress的平台，虽然很喜欢donews的氛围，但是真的不敢再跟着donews玩儿了，真的怕哪天所有数据不声不响就丢了，哭都来不及。

从现在开始，着手寻找下一个落脚点，准备搬家。（还好用了feedburner，就算搬了也不会影响订阅的朋友们。）

f1最后一站巴西站结束了，舒马赫和法拉利没能创造奇迹。其实上一站日本战比赛过后，这个结果已经在大家的预料之中了。

舒米从第10位发车，途中发生爆胎一度跌到18位，但他之后一路狂奔，经过12次超车，最终追到第4位。赛程最后阶段的两次堪称教科书式的超车，令人热血沸腾、如痴如醉。舒米先是一个假动作骗得费斯切拉冲上草地，顺利超越，之后又凭借经验与胆识硬吃下赛季顶替自己位置的莱科宁，电光石火间超车成功。他是在用毕生的赛车经验，为大家奉献一曲绝唱，即使不能获胜不能赢得总冠军，也要捍卫自己的尊严！

这站比赛有3个主角：菲利普·马萨，13年来第一个夺得巴西站冠军的巴西人；费尔南多·阿隆索，成功卫冕的年度车手总冠军；迈克尔·舒马赫，将要退役的七冠车王。舒米孤独的背影，在兴高采烈的马萨和阿隆索相形之下显得有些凄凉、有些悲壮，但在我眼中，他才是主角中的主角，王者中的王者！当前无古人（很可能也后无来者）的他选择退出，一个时代结束了。

我对f1的关注，因舒米而起，也该因舒米而终。之后的f1比赛，应该不会怎么看了。

有兴趣的朋友可以看看效果（网页浏览直接看右边栏即可）。要代码的话说一声，或者自己看源代码。

web 2.0网站命名的7个建议

作者：Michael Zhang
翻译：htmlor

开始创业时，为网站/服务命名是无比重要的一步。当前的互联网公司可以极低的成本迅速起步，似乎每隔几秒就有新的诞生。这里有些建议，有助于为你的服务恰当的命名：

1. 尽量简短

Google.com和AskJeeves.com两个域名，你认为哪个更便于每天为了搜索而多次输入？正因如此，AskJeeves才把名字缩短为Ask。如果不能在品质和功能上比竞争对手更出色，就得在服务的易用好用上下功夫。域名是否易于输入，会对访问者是否愿意经常访问产生很大的影响。我经常上CNN.com看新闻的部分原因，就是因为在地址栏里敲这3个字母太容易了。（htmlor注：在中国，QQ.com是这方面的冠军） 如果名字是一个词，长度最好为5-6个字母。名字最好不要超过两个词。

2. 要么通用 要么独创

当Flickr大红大紫，有相当多的创业者似乎认为它制定了某种Web 2.0的命名标准（htmlor注：“省略”命名法）。其实不然——命名为Locatr、Bookmarkr、Zooomr、Preloadr和Frappr等的诸多服务，并没有成为Yahoo收购行动的下一个目标。（因此我的建议是）要么以不菲的价格买下通用的、与服务性质高度一致的名字，要么有点创造性，起个与众不同、独一无二的名字。

3. 最好顺口

网站的名称不能难读或难写。如果一个名字的发音让舌头无比费劲，那就换个简单的吧。试想一下人们互相询问的情景：“你听说过网络服务PriceWaterhouseCoopers吗？”反正我是没听过。一旦名字开始口耳相传，就不应该在输入地址栏时让人产生怎么拼写的混淆。

4. 域名要用.com

任天堂（Nintendo）发布第七代主机“Wii”时，Wii.com已被人注册。幸运的是，任天堂有钱把域名买回来。如果你的钱包没任天堂鼓，就得动动脑筋起个适合.com的名字，而不是起好名字后再满世界找域名。即便域名已经被注册了，也要查查whois信息，试着找域名所有人谈谈能否买过来。你知道因为Digg的火爆而带给迪斯尼（Disney）的dig.com多少额外的点击量吗？如果Digg得回dig.com，它将如虎添翼。但我怀疑迪斯尼会不会卖。（htmlor注：是我就不卖，又不缺那俩钱儿） thefacebook.com有钱之后马上买回facebook.com，也是这个原因。

5. 避免连字符

某些特殊情况下，网站域名用连字符会好一点（如expertsexchange.com改成experts-exchange.com），但绝大多数时候还是不用为好。别只是因为不含连字符的域名已经被注册，就被迫给自己的域名加上连字符。你怎么告诉人们一个域名含连字符的网站？（很有挑战性哦） 如果Myspace的域名换成my-space.com，一天之中会有多少人输入错误？有一群专门干这行的人，他们擅于从域名输入错误中牟利。别因为你的无知而让他们大赚一笔。

6. 避免域名分段

不错，曾经有段时间给网站起类似于del.icio.us的名字是很有创意、独一无二的，但现在域名分段已脱离了个性，变得不合时宜。Yahoo购买delicious.com作为访问del.icio.us的另一个（也是更方便的）地址，或许就是这个原因。英文里的单词不是都能分成多节的，输入这种域名费脑又费时。如果出于某些原因必须使用域名分段，那么请同时也注册.com域名并指到分段的域名（像competitious.com那样）。

7. 要有含义

大家都知道，近年来通用的域名很难注册到了。不过，这并不意味着给你的服务起个高质量、有品位的名字有多难。想要名字让人印象深刻，有个简单的窍门：把一个描述性的词和一个有含义的、通用的词组合起来。比如Feed/Burner，You/Tube，Hot/Mail，Tech/Crunch等。描述性的词必须让人们一目了然，知道你是干什么的。有含义的词则要加深人们的印象，并隐含正面的信息。类似FeedPorcupine（Porcupine，豪猪）或PictureSloth（Sloth，懒散）的命名显然不符合这一点，别这么干。（htmlor注：如果你的服务就是立足于吸引眼球、哗众取宠，倒可以试试）

（完）

简单的说，css简写就是在等效的前提下，把多句css代码简化成一句。在我看来，简写css的好处有三：一是写起来方便（就像键盘快捷键）；二是简化代码；三是帮助你熟悉和深刻理解css。

闲话少说，书归正传。能够简写的css属性主要有以下几个：

font

简写：

font:italic small-caps bold 12px/1.5em arial,verdana;

等效于：

font-style:italic;
font-variant:small-caps;
font-weight:bold;
font-size:12px;
line-height:1.5em;
font-family:arial,verdana;

顺序：font-style | font-variant | font-weight | font-size | line-height | font-family

（注：简写时，font-size和line-height只能通过斜杠/组成一个值，不能分开写。）

background

简写：

background:#fff url(bg.gif) no-repeat fixed left top;

等效于：

background-color:#fff;
background-image:url(bg.gif);
background-repeat:no-repeat;
background-attachment:fixed;
background-position:left top;

顺序：background-color | background-image | background-repeat | background-attachment | background-position

margin & padding

简写：

margin:1px 0 2em -20px;

等效于：

margin-top:1px;
margin-right:0;
margin-bottom:2em;
margin-left:-20px;

顺序：margin-top | margin-right | margin-bottom | margin-left

padding的简写和margin完全一样。

border

简写：

border:1px solid #000;

等效于：

border-width:1px;
border-style:solid;
border-color:#000;

顺序：border-width | border-style | border-color

这三句也是简写，等于是把四边的样式合而为一了。（关于四边的问题，下文有详细说明）

border-top / border-right / border-bottom / border-left

简写：

border-top:1px solid #000;

等效于：

border-top-width:1px;
border-top-style:solid;
border-top-color:#000;

（和border一样）

list-style

简写：

list-style:square outside url(bullet.gif);

等效于：

list-style-type:square;
list-style-position:outside;
list-style-image:url(bullet.gif);

顺序：list-style-type | list-style-position | list-style-image

关于四边

有很多样式都涉及到了四边的问题，这里统一说明。

四边的简写一般如下：

padding:1px 2px 3px 4px;

等效于：

padding-top:1px;
padding-right:2px;
padding-bottom:3px;
padding-left:4px;

顺序：top | right | bottom | left

不论是边框宽度，还是边框颜色、边距等，只要css样式涉及四边，顺序通通都是“上右下左”（顺时针方向）。

如果四边的值省略一个，只写三个：

padding:1px 2px 3px;

则等效于：

padding-top:1px;
padding-right:2px;
padding-bottom:3px;
padding-left:2px;

（省略的“左”值等于“右”）

如果四边的值省略两个：

padding:1px 2px;

则等效于：

padding-top:1px;
padding-right:2px;
padding-bottom:1px;
padding-left:2px;

（省略的“下”值等于“上”）

如果只有一个值：

padding:1px;

则等效于：

padding-top:1px;
padding-right:1px;
padding-bottom:1px;
padding-left:1px;

关于css简写就先写到这里，大家有什么问题欢迎与我交流。

猛然发现wikipedia可以正常访问了，心情随即变得无比舒畅。

不过疑惑却也产生：是中国官员被吉米·威尔士说服了？还是wikipedia妥协了？

（注：flickr免费帐户能显示的图片最大尺寸为1024，因此对比图分成了两部分。）

9.28

下午坐上飞机抵郑，晚上到哥的公司，见到阔别8个月的哥、嫂和皮皮。皮皮开始不太认得我，玩了一会儿就想起来了。

晚上打地铺睡。

9.29

早上和嫂子带皮皮去吃早饭，皮皮摔了一跤，鼻梁上磕了道口子，让人心疼和后怕。

下午去换第二代身份证。2:20跑到3点才开门的人才交流中心，等了许久费尽周折，又跑错了一次（tmd工作人员，告诉我错误的派出所地址）之后，才赶到户口所在派出所，向路边衣店租了件黑色（浅色衣服不能照）的T恤（老板狐疑的看了我半天），拍了照，3个月后再取。

晚上见了第二天要到桂林旅游的yx，喝着羊肉汤，谈工作生活。

9.30

睡到近中午，约了近3年没见的czq见面。晚上在大街上瞎跑了半个小时才抢到一辆车，到时他已干等1个小时了。吃完饭去其住处坐了一会儿，听他兴致勃勃的谈论我并不感兴趣的野外作战趣事。

10.1

哥带皮皮参加朋友婚礼，我中午去五叔家。

下午去商场游戏厅，看到正玩的状态亢奋的皮皮：2岁多的孩子，满面红光，嘴里还含糊不清的喊着“哇塞”、“go go”，聚精会神的开赛车，整整一下午没有丝毫倦意。

10.2

睡到中午，吃饭。在这家餐馆家等了半个小时，只上了一碗面鱼儿，吃、气各半饱。

下午跟哥嫂皮皮及xl去森林公园游玩，卡丁车，越野车，轮滑，骑马，十分开心。最后在没有灯光和月光的鱼塘边钓鱼，烧烤，吃不是烤糊就是盐放的多得不象话的鱼、鸡翅、羊肉串、香肠……

晚上去k歌，虽然唱得不怎么样，还有几个五音不全（我算一个），又加上皮皮霸占一个mic持续捣乱，却是其乐陶陶、其乐融融。

10.3

归来5天之后，今天终于回到了家，见到爸妈。虽然他们5月来杭旅游过，但这次见面，又发现他们苍老了不少，尤其是妈。

爸妈看着皮皮伤痕累累的小脸，心疼不已，对“渎职”的我们当然是横眉冷对，怒不可遏。

晚上一家人聊到很晚，我也谈了下一步的打算。有些出乎意料的是，对这件风险不小的事，他们一致赞成。

10.4

一大早就被妈揪起来，让我把参差不齐的牙整整去。最后我嫌麻烦，只是洗了洗牙。比比之前的样子，果然清爽不少。

10.5

傍晚见了tc，一起吃饭。

饭后想打台球，居然已找不到影剧院了。

晚上去哥家，准备第二天参加奶奶的生日聚会。

10.6

全家人齐聚五叔家中，给奶奶祝寿。四世同堂，热闹非凡。

席间大家照例对我轮番轰炸，“关心”我的个人问题。尴尬ing……

下午大家散去，爸妈回家，我留郑。

10.7

中午去wn家里见一面，下午送他上火车。在火车站又看到最让我头晕耳鸣的汹涌人潮。

饭后和哥嫂皮皮及xl去绿城广场玩。哥又去钓鱼，效率惊人，40分钟竟钓了28条！之后又和皮皮玩球、疯跑、拍照，直到月上中空，方才离去。

晚上哥闹起了肚子，拉得痛不欲生。

10.8

中午yx、tc及ly赶过来，一起吃了顿饭，谈起同辈诸人，不免有些感慨。

哥输液一整天，晚上终于好转，幸好家里是干这行的，方便。

10.9

早上6点爬起，哥送我去机场。

坐了80分钟飞机（郑-沪），90分钟公交（虹桥-火车站）和100分钟火车（沪-杭）之后，终于到达。直接从火车站到公司，赶上了下午上班。

现在

回到住处，记这篇流水帐。

突然很想我的家人，想的不行。

google reader改版了，就在今天（官方blog）。看来几天前做的feed阅读器对比图有必要修正了。

这次改动还是比较大的，摒弃了原版某些华而不实的东西，增加和完善了一些重要特性。

好的改进：

1. 有了真正的“首页”（显示焦点内容和新闻），是大家风范。（bloglines有，抓虾跟rojo都没有）
2. 浏览分为扩展视图和列表视图，列表视图类似gmail，一看就有种亲切感。
3. 显示更新的文章数量。（这点本来就是应该的）
4. 增加了feed目录树和多feed同时阅读，顺应了用户习惯。
5. 能把文章设为“已读”。（原先只有设为“未读”）
6. 分享文章更加方便。
7. ajax效果用的很合适，用户体验很好，可谓“好钢用在了刀刃上”。

仍有待提高：

1. 还是不能显示feed描述与logo。
2. 还是没有feed订阅数。
3. 有些bug。比如点email按钮，会让浏览器（firefox）假死。
4. 一些细节不甚完美。比如有的地方叫label，有的地方叫folder，容易把人搞晕。

看得出来，google是真想把reader做好。如果能再进一步的话，我会转投它的怀抱的。

其实yahoo video本身也够大了，此次收购使得其功能更为完备，以抗衡youtube和google video。

收购金额没有披露，据估计应该接近6500万美元。而jumpcut也不过才上线6个月而已。

我现在20多岁，而今医学昌明，就算我能撑到100岁，那么还有70多年可活。足足90年的cookie我肯定用不完，至于剩下的十几二十年，只好留给儿女们了：“爹爹我平生两袖清风，没有什么遗产，幸好还有这些cookie，够你们的孙辈（我100，子女70，孙子女40，重孙子女10，皆为晚婚晚育）用到成家立业了”……

问题是，即便我能活那么久，我的电脑呢？

!@#$%^……

不管业绩如何，口碑如何，从这点小事上足以看到donews（其实是千橡，猫扑）的顾盼自雄：

丫google、yahoo、msn和百度不是保存cookie 30多年吗？有什么了不起的，我一个就顶你们仨！

（注：google和yahoo保存cookie到2038年，msn到2037年，百度到2036年，用firefox可以轻松查到。）

不过跟另一位老大比起来，这个时间根本不值一提——live（确切点说是expo.live.com）设置cookie到3000年2月8日零点过期，保存时间近1000年。

（附：又查到网易保存cookie到2100年，腾讯到2099年，新浪到2056年，搜狐到2046年（应该请王家卫当艺术总监）。）

update：吕欣欣说，此bug已改正。不过我没能测试，因为feed.feedsky.com现在无法访问。

想看看狗狗里怎么显示feedsky烧制的feed，于是添加了地址：http://feed.feedsky.com/htmlor/ 。结果让我意外：“下载rss失败”。怎么回事？难道是狗狗的bug？我又直接在浏览器里打开这个地址，却出现了“404 Not Found”错误（还能看到apache是1.3.34版本）。这下我就更糊涂了，难道feedsky down了？于是试着登录feedsky，一切顺利没有问题。哎，我彻底晕了，难道是rpwt？

发了半晌呆，我突然看到登录后页面上写着的feed地址：http://feed.feedsky.com/htmlor 。难道是多个斜杠（/）？我删去地址栏里最后一个斜杠，回车，好了！

• http://feed.feedsky.com/htmlor
• http://feed.feedsky.com/htmlor/

这两个地址居然不是一回事？我真的无语了。据我所知，在技术上使它们一致，是个极其简单的问题。

关于这一点，还是看一下别人怎么做的吧。

feedsky的直接竞争对手feedburner：

• http://feeds.feedburner.com/htmlor
• http://feeds.feedburner.com/htmlor/

del.icio.us：

• http://del.icio.us/htmlor
• http://del.icio.us/htmlor/

flickr：

• http://www.flickr.com/photos/htmlor
• http://www.flickr.com/photos/htmlor/

这个低级失误，狗狗好像也有：

• http://www.gougou.com/name/htmlor
• http://www.gougou.com/name/htmlor/