We are ?
由于时间、精力关系，本文demo都是基于webkit内核写的，请使用chrome或Safari阅览。
上面这个《We are》是ReeQi前段时间玩CSS3动画写的，20多S的动画，竟然花了3h+，还是借助animate.css的，实在是惭愧。当然，这个简单的动画过程也加深了我对CSS3动画的理解，今天就跟大家分享下CSS3动画的时间轴。
我们知道时间轴是形成动画的基础，不管是古老的走马灯还是现代的动画，都是基于时间轴上一帧一帧的变化形成的。
Flash的时间轴是以层为基础的时间时间轴集：
而对于CSS3中最引人瞩目的特性之一，CSS3动画，自然也有它自己的时间轴。CSS3动画的整个时间轴，主要是基于以下几个属性来完成的：
animation-delay
W3C官方早已对这两个属性有详解，这里就不赘述了，这里提供两个传送门大家可以看看：
W3C animation-duration-property
W3C animation-delay-property
CSS3中文手册CSS3动画部分
animation-duration
animation-duration指的是动画对象的执行时间，也是整个keyframes的执行时间，也就是keyframes里定义的from{…}（0%）到to{….}（100%）的时间，而很多时间我们会这样写keyframe：
0% { ....}
50% { ....}
100% { ....}
}
如果animation-duration设置为1s的话，也就是0s的时候是0%{…}这种状态，0.5s的时候时候是50% { ….}的状态，1s的时候是100%{ ….}的状态。通过那个百分值来对animation-duration设置的时间进行切割。在我看来，每个百分值就相当于flash里的关键帧。
animation-delay
再看animation-delay，指的是动画对象延迟多少时间才开始执行，这个好理解。但比较麻烦的地方在于，多个动画对象一起运作的时候，animation-delay的设置就比较复杂了。
比如下面的小需求，第一个元素执行1s结束后，第二个元素开始执行，第二个元素执行一半后，第三个元素才动：
这个简单的动画三个元素的animation-delay设置如下：
-webkit-animation-duration: 1s;
-webkit-animation-delay: 0s;
}
.no2{
-webkit-animation-duration: 1s;
-webkit-animation-delay: 1s;
}
.no3{
-webkit-animation-duration: 1s;
-webkit-animation-delay: 1.5s;
}
@-webkit-keyframes delay_test{
0%{width:100px;}
50%{width:200px;}
100%{width:300px;}
}
题外话：其实上面的效果也可用Transition实现，关于transform、transition、animation的区别，看官可以点这里：CSS Transform / Transition / Animation 属性的区别
这算是最简单的动画了，当一个动画里的元素越来越多，animation-delay就更加复杂了。所以如果手工写CSS3动画的话，肯定会有大量的时间是花在对时间轴的调整上的。
前段时间因项目需要，在处理批量删除DOM节点时老是没删干净，恰得猫哥点拨，故在此记录下。大家先看DEMO： 提示：你可以先修改部分代码再运行。 从代码不难看出，第一个批量删除DOM用的是正序循环： 第二个批量删除DOM用的是倒序循环： 其实很好理解，用正序循环的话，i=0，然后i逐次递增。i与要删除的DOM关系如下： i —— li.length —— 删除的li 正序循环删除是从前往后删，循环体在删除DOM节点后，但i指向的节点也发生了变化，如i=0时，li[1]应该指向的是第二个元素，经过removeChild()，前一个的li[0]被删除，所以到第二次循环，即i=1时，原来的li[1]实际上已经变成了第二次循环的li[0]，但因为i依然是1，所以就变成指向最初的li[2]，即第三个元素，从而跳过了第二个元素。后面的以此类推。 而倒序循环删除，则如下： 倒序循环是从后往前删，每一次执行循环之前，都会去获取最新的length，再通过i指向最后一个元素，从而避免了正序循环的问题。如i=5时，删除了最后一个元素li[5]，即第6个元素，第二次循环（i=4）时，删除的li[4]还是最后一个元素。依次类推。但因为每一次都要去获取length，多少会有性能问题。 其实，只是简单删除所有子节点的话，直接清空也就是了。呵呵。。这里只是通过这个例子学习正序倒序循环的一些区别。 2012就这样来了，这个年份似乎容易让人感到不安，世界末日？Maybe…..反正船票买不起，就听天由命呗，尝尝今朝有酒今朝醉的感觉也不错… 毕业，还记得穿着学士袍在校园到处找人拍照的情景，还记得跟兄弟们晚上出去劈酒，还记得六班的兄弟姐妹一起在操场上敞开心扉地交谈、哭泣的那个通宵夜…四年的大学生活在那晚画上了一个句号。。感谢四年里面遇到的人和事，是你们给了我如此精彩的四年，虽有遗憾，但亦无憾矣。
就业，结束实习，入职，转正，真正成为一名前端攻城师，算是人生中的一个重要的转折点，也认识了好多好多牛人。这一点上，我是幸运的，要感谢的人很多，万语千言一句话，谢谢……这条路还有好长好长，我还远不够格……2012要继续拼！ 感情，跟舒儿平稳地度过了第七个年头，虽然难免地闹些小矛盾，但对彼此的理解支撑着身在异地的我们……毕业了，似乎平添了几分责任，似乎要谋划些什么了……祝福舒儿，祝福我们…… 变成一名文艺青年，每个周末都背着单反到处逛，碰到有感觉的东西，会很二地在那里拍上半天，越发地喜欢有feel的地方……还有就是喜欢寻觅深圳街头小巷的美食和故事……或许是独自一个人在异乡吧，总是要给自己找些乐子，不然生活太无趣了，我会得抑郁症的！另外一方面是珍惜吧，珍惜身边一切美好的东西……哦，有件事不得不提，终于造反了，实现了多年的愿望，虽然还是分期付款ing…… 2011年，对我来说，算是挺哈皮的一年，顺利毕业，顺利就业，家人身体健康，大哥成婚。好多值得纪念的事，感谢上苍的赐予，感谢命运的垂青，感谢…… 回过头来展望2012，虽然不知道会不会有2013年，但如果说2011是我的一个过渡年的话，2012就是我的真正开始新生活的一年了！我的生活还是过于随意，有时候总拖拖拉拉的。所以在新的一年，首先要做的是改变自己有些随意有些懒散拖沓的生活。规划好了的就要坚定地执行。以往有规划，但执行过程中，有些计划总会因为懒散拖沓而胎死腹中。2012年我首要要改变的就是我偶尔拖沓的习惯！如果能改变，一切将会水到渠成。生活、工作效率、专业技术、理财都会上一个台阶。 林林总总写了这么多，各位看官且当流水账视之，呵呵…… 走过了2011，一切如浮云，会渐渐掩埋在记忆的尘埃中…… 2012，本命年，或顺，或不顺，都将珍惜之…… 珍惜身边的每个人，珍惜遇到的每件事物…… 如果真的有世界末日，我只愿无悔地对天地言，我曾经精彩地活过，如此足矣。。 尽管心中有一个已经永远无法实现的愿望…… 但最后还是要祝福我爱的，还有爱我的人…… 新年快乐，一切顺利！ 贴一下上周在组内分享的PPT——{LESS}CSS is more ！？为什么我的标题还加上问号呢，因为经过我对less的学习和使用，发现less并不是像我们想得那么美好，它真的能让我们的效率得到提升吗？真的使我们的代码变成“少即是多”么…. 最近做了一个艰难的决定….把一个页面的背景图从一个拆成N个，靠！这也算艰难吗….其实对于一个有历史，背负着页面测速KPI权重的页面来说，这个决定不可谓不艰难。 我们都知道网速优化的金条玉律：减少HTTP请求。所以为了达到测速KPI，我们疯狂地使用CSS Sprite，疯狂地合并CSS，JS，应运而生的自动化压缩合并工具（系统）不计其数。我们曾经坚信我们做的这一切是正确的，都是在为公司节省带宽消耗。 当然，为公司节省带宽消耗是一定有的，但另一方面却带来了一些问题：页面维护性降低了，维护成本和风险变大了；另外最重要的一点是：我们的测速KPI达到了，用户体验却差了。。 一频道页面只有一张背景图，20K+。请求少，很OK。 但有个问题：页面从上到下到引用了这张背景图，包括头部导航（维护性方面的问题这里就不说了）。而导航文字又是白色的，当网络环境不好的时候，刚打开页面，在没有cache的情况下，背景图较大，没能马上加载完，导致导航一片空白，突然当的一下，背景图加载完毕，导航出现。用手机浏览器访问，这种现象尤其明显。。这样的体验可想而知。 这个问题不难解决，给头部导航加个背景色即可。但是这是治本之法吗？ 先放下上面的例子。把页面的背景图合并成一张，为了减少HTTP请求，为了网速优化，为了测速数据好看些，为了达到测速KPI。MS是一个不错的逻辑。彪叔在一次分享会上提过：一个页面的测速成绩很赞，Why？因为它每个模块都是iframe的…我们的网速优化是为了达成我们的网页测速KPI么。 像上面的例子，你的页面测速成绩再好，用户在打开页面的时候感觉不爽，那网速优化又有个鸟用。。所以，我们永远不要忘记低端用户。尽管减少HTTP请求是铁律，但也要以用户的感受为前提。 不过似乎如果扯上KPI的话，很多同学就会选择忽略用户体验。 如何保证体验，又能达到KPI，这里应该有个平衡点。比如上面的例子，将色值相近的背景图合到一起，更加合理地压缩图片，等等这些都能达到优化的效果。由此可见，只有一张背景图不见得就好，有多张背景图不见得就不好。 所以，网速优化的导向应该是用户（体验）。 在HTML5中，a标签里面嵌套其他块级元素（如div等）是合法的。但在(X)HTML和HTML4是不被允许的。这样就导致了这种写法在不给力的低端浏览器（你懂的）下容易出现各种诡异的问题。就像今天我要吐槽的a 标签里的其他块级元素在a:hover下的展示问题。 需求描述： 提示：你可以先修改部分代码再运行。
BUG描述：
BUG修复： 提示：你可以先修改部分代码再运行。 但是很快一个新问题出现了：鼠标移上去，OK，隐藏的元素出来了，但鼠标移走后，在IE6下顿时傻眼了，内容走了，但背景色竟然就不走了…..哭死….（IE7是正常的） 提示：你可以先修改部分代码再运行。 BUG分析： 提示：你可以先修改部分代码再运行。
这个bug的修复方法上面已经提到，就是将内部元素的背景色（图）或border移至a:hover的状态下。个人认为是IE6下，a:hover后，内部元素的样式继承出错，无法继承原来的样式造就了这个bug，而只是个别的属性会这样：background、border。笔记：循环批量删除DOM节点
li[i].parentNode.removeChild(li[i]);
}
li[i].parentNode.removeChild(li[i]);
}
0 ———- 6 ————- No.1
1 ———- 5 ————- No.3
2 ———- 4 ————- No.5
i —— li.length —— 删除的li
5 ———- 6 ————- No.6
4 ———- 5 ————- No.5
3 ———- 4 ————- No.4
2 ———- 3 ————- No.3
1 ———- 2 ————- No.2
0 ———- 1 ————- No.1写在末日前的回顾与祝福
简单回顾下2011吧…
{Less} is more !?
网速优化导向
IE6 a:hover 内部元素背景BUG
如上图显示，鼠标在移到商品图片上显示隐藏的半透明层。当然，实现这个需求的方法有很多，对高端浏览器可以用伪类的写法，对低端浏览器可以用JS的方法。这里我们暂且选择用a标签嵌套所有信息的写法。提炼下，形成以下DEMO代码：
如上面的代码，一般思路是a标签用CSS重置为display:block;和position:relative;需要隐藏和遮罩的元素position:absolute;，设个背景色，接着display:none;，然后a:hover的时候展现该元素，即display:block;。以上思路在IE8+，FF，Chrome下是可以完成需求的。但是在IE6就杯具了，鼠标移上去之后隐藏元素死活不出来 ！- -
后来发现，只要在a:hover上加上：border:0、border:none、background、background:url(data:)任意一个就OK了：
再次不断地尝试，终于找到了方法：把隐藏元素的背景色转移到a:hover时的该元素上，OK！问题完美解决！
出现这个bug，需要有下面的条件：
各位大神不妨拍砖，探讨下。