Cutsin受难记

看了历史频道的《远古外星人》，你就会发现：什么圣经、佛法这些全都是扯

人往往只相信自己所能认识得到的

一切皆有可能，信什么都无所谓

一切只有一个原因：谁都无法接触到事实

太无知了

如果谁能给我一切的一切的的事实、答案，我现在死都可以

娱乐的根源也在于：有你未知的东西

唯心、唯经验，我都烦

不过，每次去乡下干活，站在地里、山上，都会对以下几个字印象深刻：

然后看着来乡下玩的城里人，我脑子里总闪过一个印象：
sb们……
各种装……

圈子、圈子、圈子……
圈子跟圈子根本没有交集，但人可以改变他的属性
或者说是角色转换

书上总说“内心无比丑恶”

以前只觉得是个字面意思而已，仔细想想，我心里再丑恶，别人不知道

我想把周围的人聚在一个屋子里，然后全杀了，别人也不知道

避免极端的最好方法，就是设想各种极端；
避免丑恶的最好方法，就是模拟各种丑恶；

总担心害怕什么，就去正视什么
这样很坦荡，舒服

所谓不问时事，不理诘讽，可多活几年，就是这个意思……

教育，其实也是个自我认知的过程

所以我喜欢看牛人的平易近人的自传，他们总有很多对生活的认知

看正确的书，活想要的人生，呵呵。

出场角色：他、Komo（他的前任Leader）、Alex（他的同事）、Robin（他的现任Leader）、Haven（现任交互设计师）

1、
他刚来的时候，经常不听Komo的意见和建议，对于产品的看法，几乎听不进别人的意见；

2、
有一次因为什么事，他和Komo吵得很厉害，Komo很怒，
然后Alex把他叫到另一个办公室，告诉他为什么、哪里有问题；
后来他独自一人站在公司楼下抽烟、抹眼泪，
正好我经过，他想跟我聊聊，然后就诉苦：不被理解、认为Alex他们也没什么能力之类，
我只能安慰他、讲道理，告诉他机会在哪里，什么时候会出现……
聊了近一个小时，分开时他说很感谢我

3、
他即将转正的时候，Komo不想留下他，然后问了Alex的意见，
Alex说他年轻，需要磨砺，可以再给他一些机会，
然后他留下来了，往后的日子里，我和他不断有些接触，谈谈理想、聊聊琐事，
他说他的理想是做出一个像douban.com那样了不起的产品
一切都很正常、平静。

4、
Komo没等到新项目上线就离职了，由于一些原因，他受命接任产品经理，
但在这期间“他对产品设计上没有提出任何实质性意见和改变，甚至在产品上没有任何的想法。”
——我以为如此。
可能由于直接向Robin汇报，或者什么别的原因，他开始膨胀，对大家的也态度急转直下；
他在行动上很积极，跑来跑去的，看上去很负责任，
只是他不再虚心做产品设计了（虚心——也许试用期的时候就没有过，尽管他身边贴着座右铭“兼听”）
他像个项目经理，不断地盯每个节点，询问resource；
他也像一个测试经理，甚至捧着计算机有事没事地在你旁边等你解决bug，天天催着bug什么时间能解决；
他更像个大Leader，每天把大家叫在一起站成一个圈，挨个问询；
他让自己”忙”起来了。
我不知道他在忙什么，我没有看到他忙的事情对上线、效率或是别的有什么帮助。

5、
这期间，我几次听到他跟某些同事在嘲笑Alex；
而当他以任何方式表现出对Alex的不屑时，他并不知道我上面提到的第3件事。
此时我对他的不满情绪开始流于言表。

6、
一个小团队去封闭开发了，他在其中。
他仍扮演着项目经理的角色，“遥控指挥”着仍在本部的大家。——我理解为指手画脚。

一件事情的发生，也是促使我写下这篇文字的原因之一：

大Boss提出对一个外部接口的修改需求；
他不负责任地（在我看来）开始推进提案，到我这个环节时，
发现许多一看就不合理的问题（有人说是拍脑袋——我觉得这次是拍屁股）；
我把提案退回需求方，提供了这个东西的来龙去脉、原始需求、当前实现、衍生产品的展现；
然后他一个电话打过来：”你觉得有什么问题？！”
我@#%$%@^，我的情绪开始激动，一顿争吵后不了了之；
其他细节就不说了，后来把本应这个环节解决的问题推给了UI组的Leader；

后来封闭暂停了，他回来后，又来絮絮叨叨问这问那（都明确说自己不负责了，还来磨叽什么？），
我情绪全写在脸上，无法忍受，抽身离去，
他在后面高声质问了我一句：“xxx你态度能好一点么？这已经不是第一次了！” ——好，我承认我态度有问题，但想不出他是否能承认什么

不靠谱的改动仍在继续，临上线前，除了之前几个没人愿意搭理的问题（比如接口、衍生产品的展现）外，都18:00了，还在fix 2个明显缺陷：1是乱码；2是交互缺陷；
Haven的表现也很让人失望，本已点头确认的确是有问题了，
而且我也给出2个方案并明确告知”交互的事情你说了算”，
最后却说：”那这是他给的文案”、”来不及修改了”……
这明显是基于”不担别人责任”、”自己只负责好自己的东西”的想法么！
最后测试同学熬到20:00还在测，也是建议不上线，but无人回应，还是上线了。

此时他应该早已淡忘了我上面提到的第2件事。

7、（这里是后话了）
第6件事中的项目上线后，出现了一系列问题，Boss开始问责；
我把所有的事情，都告诉大Leader了，大Leader人很好，也很诚恳，但，仅仅是我被安抚了。

其实我比较淡定，因为之前看了一篇有如醍醐灌顶的文章：http://coolshell.cn/articles/4951.html

愚以为这件事情，可能还是大家做事到底是面向项目，还是面向产品，或是面向团队的问题。

上面提到Haven的表现，其实不怪他，很多同事都是这样的想法，包括我最后也在说”好，我听你们的”——我累了。

过去的事情，就让它过去了；
过去的教训，不会随便就忘了；
要求信任、不要多想，也不是靠说就能”纠正”了的；

我明白自己需要改掉的缺点还很多……
很多人总以为我们要走的路还很长……

如果我信命，为什么会困惑……

在做#skyLand框架时，发现chrome的一个渲染bug，草草解决了。然后被同事再度揪出，囧……
幸好它真的是chrome的bug，遂总结纪念：

w3对visibility:hidden的解释：

1. visibility可继承；
2. 属性值hidden使元素不可见（全透明，不渲染），但仍然影响布局。另外，该元素的后代如果设置了属性值visible，它们会是可见的。

由此我们应该认为下面例子中，不管点哪个按钮，#boy、#girl都应是同时可见的：
<style>
.parents {visibility:hidden;z-index:1;position:relative}
.parents div {visibility:visible;position:relative}
.noDis {display:none!important}
.noVis {visibility:hidden!important}
</style>
<script>
function $(o){return document.getElementById(o)}
function showKids(s){
$('boy').className=''
if(s)
$('girl').className=''
else
setTimeout(function(){$('girl').className=''},0)
}
</script>
<button onclick="showKids(1)">show kids</button><button onclick="showKids()">show kids later</button>
<div class="parents">
<div id="boy" class="noDis">Go! Daddy~ ^^</div>
<div id="girl" class="noVis">Hi! Mommy~ ^^</div>
</div>

但在chrome中，点show kids later后，#boy不见了，其他浏览器正常。
现象分析：

1. 初始时，父元素设invisble，子元素设visible且display:none，动态移除display:none时，webkit未能更新
2. #parents中，只要初始时存在任何visibility:visible的元素，其他元素（如#boy）的渲染就能正常
3. 如果渲染失败，用鼠标反选一下也能正常显示

然后，

1. 点上例的show kids later，用setTimeout将#girl和#boy“分两步”处理，渲染失败
2. 点上例的show kids，同时处理#girl和#boy，渲染正常

猜到的可能原因是：chrome(当前版本13.0.782.112)对渲染做了某些优化（比如执行缓存），但存在bug，同样webkit内核的safari正常。

总结该bug的触发条件：

1. 父元素visibility:hidden，position非static，z-index非auto
2. 初始时，父元素内部没有任何计算值为visibility:visible的元素
3. 内部元素（且称为bad）visibility:visible，position非static
4. 初始时，bad的display为none

然后，bad改变display为非none时，无法渲染。

原因清楚后，最终的解决方法也很简单，增加默认visible的元素即可：
.parent:after {visibility:visible;content:''}

错误示例页：http://moonless.net/demo/30

大概所有人都会接触到这样的设计：

于是逝去的日子里发生过类似下面的变迁：

• 有时它是静态的，我们会这样写：
  <a href="#">音响</a> | <a href="#">课本</a> | <a href="#">西红柿</a>缺陷：内容动态修改非常麻烦、不便扩展。
• 相当长的一段时间里，变成了这样：
  <style>
li {float:left;padding:0 0 0 7px;margin:0 0 0 6px;background:url(竖线.gif) no-repeat}
.first {padding:0;margin:0;background:none}
</style>
<ul>
<li class="first"><a href="#">音响</a></li>
<li><a href="#">课本</a></li>
<li><a href="#">西红柿</a></li>
</ul>缺陷：样式与程序耦合，可能前后端都要麻烦个遍。
• 再后来开始利用overflow:hidden以及text-indent：
  <style>
ul {overflow:hidden;text-indent:-13px}
li {display:inline-block;text-indent:0;padding:0 0 0 7px;margin:0 0 0 6px;background:url(竖线.gif) no-repeat 0}
</style>
<ul>
<li><a href="#">音响</a></li><li><a href="#">课本</a></li><li><a href="#">西红柿</a></li>
</ul>缺陷：溢出隐藏，无法在<li>中放置其他元素，比如气泡、下拉菜单等等。

最终的解决方案（简化）：
<style>
.noDis {display:none}
.tags {*zoom:1;display:block;text-align:left;_text-indent:0!important}
.tag {display:inline-block;*display:inline;*zoom:1;padding:0 0 0 5px;margin:0 0 0 5px;text-indent:0;_text-indent:-10px!important;white-space:nowrap; vertical-align:top;background:url(竖线.gif) no-repeat 0}
.tag a {text-indent:0!important}
.tag:first-child,
.tag[class~='noDis']:first-child + .tag {padding-left:0!important;margin-left:0!important;background-image:none!important}
</style>
<ul class="tags" onmouseover="this.firstChild.className='tag'">
<li class="tag noDis"><a href="#">音响</a></li><li class="tag"><a href="#">课本</a></li><li class="tag"><a href="#">西红柿</a></li>
</ul>
几点说明：

1. 利用IE6的一个bug：父元素hasLayout、子元素position:static时，子元素溢出父元素不会被显示
2. <ul>和<li>之间不能存在注释，IE7会把注释当作childNodes导致firstChild选择错误
3. noDis是一个附加需求，即：鼠标滑过tags区域才显示“音响”，所以产生了一个问题：如果不将“音响”remove掉，那么浏览器仍然认为“音响”是tags的firstChild，这样“课本”的竖线仍然会显示，这不是我们想要的，还好除了IE6，多数浏览器都支持相邻选择器“+”，于是我们增加一条逻辑：“当firstChild的className包含noDis时，它的nextSibling同样隐藏竖线”
4. 之所以ul、li都加上了className：tags、tag，是为了避免li中再出现ul、li，稍显冗余，可避免后患。
5. 有一个小遗憾是竖线用了图片，不便换肤，但考虑到这样可以很方便地换成横线、点、虚线等乱七八糟的分隔符，这点牺牲还是值得的。
6. IE7的firstChild有个bug：在静态firstChild前面插入新元素，IE7不会更新样式，此类需求很少，不管了

呼…… 世界和平。

以下内容仅在lang=”zh-CN”，charset=”gbk”环境测试通过。

需求1：
新项目中，默认的中文字体是微软雅黑，虽然我始终认为雅黑不适合大面积阅读，but it’s my job.

需求2：
项目上线后，和最初的担心一样，出现许多不满的声音，于是，需求又来了：让用户可以自行选择字体。
在固执的我看来，这是拿错误的方法去解决错误的问题，but that’s my job.

实现过程中几个值得注意的问题：

1. font-family的理想书写顺序
   要兼顾win/mac，应是：font-family:Helvetica,Tahoma,Arial,'Microsoft YaHei',sans-serif目的显而易见：
   英文字体的显示，mac优先Helvetica，而win中通常没有，所以默认Tahoma，备用为Arial；
   中文字体的现实，优先雅黑，如果没有遵从系统的fallback规则；
   按照标准，sans-serif置后，如果不加，一些浏览器会解析错误。
2. 对付win的font mapping
   由于win注册表里的font mapping会将Helvetica映射为Arial，所以Tahoma不会生效，而且实际上Arial也不会生效，直接显示为雅黑，纠结了好久，就在几欲放弃Helvetica之际，救星出现了，它就是Helvetica Neue，绝大部分mac用户的系统上都有这个字体，而这个字体不在win的font mapping中，虽然它看起来要粗壮一些，貌似macOS/iOS会自动根据分辨率、字体粗细调整Helvetica字族的显示，看数据可知：Helvetica的安装率接近100%，Helvetica Neue在95%左右，而twitter, wordpress等，也是不约而同地用它作为前置，so，它是可靠的。
3. IE6/7中，如果用户自行更改了浏览器默认中文字体，而font-family中的中文字体前面设置了英文比如（Arial,SimSun），那么此font-family会被无视
   没找到解决办法，只能将中文字体放在最前面了。
4. IE8/9中，如果用户自行更改了浏览器默认中文字体，而font-family指定了sans-serif，那么此font-family会被无视
   而如果统一不写sans-serif，chrome等部分浏览器，也会无视font-family，纠结了好久，还是上hack……
   但由于常用的\9、\0不能用于font-family，所以只能祭出@media screen\0

综上，最终的方案如下：
body,input,textarea,select {font:normal 12px/1.667 'Helvetica Neue',Tahoma,Arial,'Microsoft YaHei',\5fae\8f6f\96c5\9ed1;*font-family:'Microsoft YaHei',Tahoma,Arial;color:#333}
.noClearType body,.noClearType input,.noClearType textarea,.noClearType select {font-family:Tahoma,Arial}
.FontYahei body,.FontYahei input,.FontYahei textarea,.FontYahei select {font-family:'Helvetica Neue',Tahoma,Arial,'Microsoft YaHei',\5fae\8f6f\96c5\9ed1,sans-serif;*font-family:'Microsoft YaHei',Tahoma,Arial}
.FontSimsun body,.FontSimsun input,.FontSimsun textarea,.FontSimsun select {font-family:'Helvetica Neue',Tahoma,Arial,SimSun,\5b8b\4f53;*font-family:SimSun}
.FontSys body,.FontSys input,.FontSys textarea,.FontSys select {font-family:'Helvetica Neue',Tahoma,Arial,sans-serif;*font-family:'Helvetica Neue',Tahoma,Arial}
@media screen\0 {
.FontSys body,.FontSys input,.FontSys textarea,.FontSys select {font-family:'Helvetica Neue',Tahoma,Arial}
}

其他阅读资料：
http://www.99css.com/archives/830
http://lifesinger.wordpress.com/2011/04/06/best-web-default-fonts/

png-8（也叫索引色png、调色板png）支持256级透明度，但这种文件类型通常不被png处理程序所支持。
之所以不被支持，也许是因为很多程序对它支持不好吧，以IE6为例：

1. 众所周知的半透明区域渲染失败（通常表现为灰色背景）；
2. png-8的半透明区域部分渲染失败（通常不显示）

如果你愿意，利用这个不显示的“特性”做做文章也是可以的，而且效果尚可，例（分别用IE6、其他浏览器打开）：
http://www.moonless.net/demo/29/

（用PngOut Plugin for PhotoShop可以生成上述例子中的图片；fireworks更方便。）

参考阅读：http://www.ardfry.com/png-plugin/Tour.htm

效果预览：

修改方法（以CS5.5为例）：

一、关掉Dreamweaver：

1、用修改过的Colors.xml替换至（请先备份原文件）：C:\Users\Administrator\AppData\Roaming\Adobe\Dreamweaver CS5.5\zh_CN\Configuration\CodeColoring\

2、安装压缩包中的所有字体文件

3、打开注册表编辑器（或执行dreamweaver.reg），找到：HKEY_CURRENT_USER\Software\Adobe\Dreamweaver CS5.5\Font Preferences分别修改CharEncoding_14、CharEncoding_15、CharEncoding_16、CharEncoding_7里面的Fixed Name、HTML inspector font、Proportional Name值为“Droid Sans mono”，将各种Char Set均改为“0”

4、修改windows设置，如图：

二、打开Dreamweaver：

1、修改代码视图背景色，如图：

2、在“首选参数” > “字体”里，将Unicode、西欧、简体中文、繁体中文等字体名称都改为“Droid Sans mono”，大小均为10pt即可

善待眼睛，不舒服就改掉它。

[2010-11]
引子：用拼音是不得已的事情，有时候无法或不愿区分性别，虽然只有2个字母，但究竟怎么书写才好呢？

1. 印象汉语拼音方案中，除了专有名词、人名、句首才需要大写（而且是外来的英文习惯），除了牌匾之类，没有全部大写的；
2. 记得看过一篇文章，说只有使用拼音文字作为第一语言的人，才较习惯全部大写的认读；
3. 作为注音符号时，全部小写更容易认读；大写会造成一定的阅读障碍

so, 感觉ta或Ta更符合国内的认读习惯……  orz

[2011-01]

一、“为什么还在用难看的宋体方块字。”

1、宋体之所以被批评为“难看”，是因为它没有包含足够的hinting（字体的额外资讯，它告诉render该如何处理细节部分，使得在不同大小时能够好看）， 所以当字号小于8pt(11px)或大于14pt(19px)时，会出现断裂、残缺、粗细不均的情况；

2、很多人以为从vista开始，windows的默认字体是微软雅黑，但他们也许不知道：xp的宋体版本为3.03，从vista开始已经完全改为 5.0，并且同时使用2种默认字体：在GUI界面、标题文字、帮助文档等重要的地方，使用微软雅黑；在正 文部分（如记事本的内容，默认没有指定字体的网页）、阅读区域，实际上使用的是宋体5.0；只不过，宋体5.0比3.03要“胖”一些、“圆”一些，所以用户不易区分它，甚至误以为是微软雅黑。

3、关于微软雅黑和宋体哪个更好，一般有2种看法：

1. 多数人会说：这是个主观和习惯的问题；
2. 有2个词：“易读性（legibility）”、“可读性（Readability）”；

宋体的笔画清晰，阅读轻松，容易识别，特别适用于正文这类 文字密集的地方，它能够沿袭一千多年不是没有道理的。

微软雅黑，它的出现主要是为了解决宋体的上述缺陷，即不可读问题，但后来大家慢慢发现它的易读性很糟糕：笔画高低不平、颜色较淡、边缘五彩斑斓……

从易读性角度看，有人把它比作“美术字”，而此类字体通常被认为是不适合长时间阅读的，很容易疲倦。

而这些缺陷的原因，除了由于雅黑本身的Hinting信 息仍不是那么精细外，另一个重要原因在于ClearType。ClearType提出的初衷是因为LCD没法很好的显示小字号的点阵字体，所以要亚像素去 填充锯齿，关于它的原理和缺陷这里有篇详尽的介绍：http://www.xieyidian.com/?p=1057；
c. 然后是2种字体的阅读对比：
宋体14px：http://www.moonless.net/demo/27/
微软雅黑14px：http://www.moonless.net/demo/27/2.html

二、“某些网站的css支持雅黑”，“font-family: Arial,Helvetica,sans-serif;”

这是个错误的写法。

它的初衷是想让macOS能够使用Helvetica字体，但写反了，Arial在macOS中同样普遍存在，这样 helvetica根本没有被使用到的机会。正确的写法至少是：font-family: Helvetica,Arial,sans-serif;

另外，如果不设定中文字体，浏览器会去寻找os的字符映射，但如果字符映射错了（比如 linux用户自行修改过），那么显示的既不是宋体，也不是雅黑。

三、“我突然发现有些网站也开始支持雅黑字体了”

有些用户使用了类似“火狐中国版”这样的浏览器，它们默认不允许站点使用 css指定的字体：

四、全文改成微软雅黑的技术问题

1、除了上面提到的易读性问题，IE拖动页面时，雅黑体抖动会更明显；
2、微软雅黑、宋体3.03、宋体5.0的x-height不同，垂直对齐文字中的icon、表单控件等行内元素很困难，如果找不到折中方案，无法区分它们