在Google首页经常可以看到一些小动画，一般第一感觉会认为是GIF动画，其实稍微分析下代码就不难看出是用JavaScript+PNG实现的。
简述下其相对GIF动画的优势：
当然关键还是要看项目是否有这需求，一般项目很少有这需求。
实现这个动画的方法很简单，下面是我自己写的实现方法，基本没有出现不兼容问题：
提示：你可以修改代码后再运行。
先看张网络上的图，来源不明，从使用的浏览器看应该很老的图了，不过还是挺经典的，非常好的诠释了这些属性的区别。
整理的文字说明：
offsetHeight：元素的高度（可见部分）
offsetTop：当前元素的外边界（可见部分）到其父元素的内边界（可见部分）的距离
offsetY(IE)/layerY(FF)：事件触发时鼠标指针相对于目标元素外边界（可见部分）的坐标位置
scrollHeight：元素的完整高度（包括不可见的如margin,top部分）
scrollTop：当前元素到其父元素内边界的距离
clientHeight：元素的高度（不包括不可以见部分和滚动条部分的高度）
clientY：事件触发时鼠标指针相对于当前页面中的坐标位置
screenY：事件触发时鼠标指针在整个屏幕中的坐标位置
(event.clientY+body.scrollTop)(IE)：事件触发时鼠标指针相对于目标元素的父元素的外边界的坐标位置
关于event.Y和event.clientY的区别，当目标事件的position为relative时，event.Y返回鼠标指针相对于目标元素的外边界（可见部分）的坐标位置，在火狐里可以通过而event.clientY依然是相对于当前页面的坐标位置
同一个元素的 scrollHeight≥offsetHeight≥clientHeight
至于offsetWidth,offsetX等横坐标上的属性同理，不赘述了。
这里做了一个测试代码：（代码在不同浏览器下还存在兼容问题，有待后面再做改进）
提示：你可以修改代码后再运行。
部分文字参考自：w3school
SEO虽然是项独立技能， 但作为前端还是需要了解和熟悉的，相信搜索引擎想要的，也是用户想要的，所以就算从用户角度出发，也要掌握SEO技术。下面就是对SEO有利的HTML标 签，算是入门级的东西但又很重要。从SEOWHY上看到的文章，把关键部分提取了下，就当做个笔记，原文在这里。
不知道什么时候开始养成了这样一个洁癖，就是要让写完的页面在去掉css后同样能拥有非常好的阅读性，这样做可能是有些得不偿失，但如果优化的好，对搜索引擎抓取和一些特殊设备的读取还是有利的（当然这个还有待考究）。
就拿最近写的一个Tab切换效果来说，通常情况下，Tab的标题和对应的列表是分开的。比如腾讯的这个Tab切换效果，在渲染后的情况是：
屏蔽css后：
所以如果要让页面在屏蔽css后还能让标题和相应的列表是在一个盒子内，做起来相对麻烦一点，下面就是自己写的效果在渲染后的情况：
屏蔽css后：
最后贴上效果页面，点击查看Tab切换效果，已知的不足之处：盒子的宽度高度都是固定死了，扩展性不佳，另外行为是用jQuery实现的，效率不高，还可以做更多优化。
用JS简单的模拟了文章归档的导航菜单，无需读取数据库。
缺点是不能显示文章数量，对搜索引擎也不够友好。
提示：你可以修改代码后再运行。
给朋友做的一个地图，要在鼠标移到城市名字上时显示相应城市的新闻数量的提示，而且提示能跟随鼠标移动。
没什么技术含量，主要是在城市名字定位上繁杂点，然后行为效果是用jQuery实现，一行代码就搞定，JQ真是省油的灯。
点击这里查看效果
两个小知识点：
event的兼容性，所以无需判断是用event还是window.event。pageX兼容IE，可以得到光标相对文档顶部的坐标（包括滚动条已滚走的距离）。例子胜过废话，请猛击下面：
10步掌握CSS布局定位： position static relative absolute float
原文：Learn CSS Positioning in Ten Steps
翻译：10步掌握CSS布局定位
目前除了IE6和IE7两个活宝外，其他主流Browser（Chrome,Safari,opera,IE8,FF3等）都已开始支持display:inline-block，所以基本仅需要针对IE6和IE7做兼容处理，网上已经说烂了，还是留个笔记吧，此法对IE5.5也有效。
方法一：
div {display:inline-block;} /* 触发块级元素的layout */ div {*display:inline;} /* 再设置为行内，*号是为只支持IE7及以下版本 */
方法二：
/* 先设置为行内，然后用 zoom:1 触发layout */ div {display:inline-block;*display:inline; *zoom:1;}
1em=1*父元素字体尺寸
2em=2*父元素字体尺寸
3em=3*父元素字体尺寸
…（以此类推）
如果所有父元素都没有设定字体尺寸，则“父元素字体尺寸”换成浏览器的默认字体尺寸（一般来说都是16px）。
当然em还可以用于容器尺寸和文本缩进，设定的尺寸是根据当前元素（如果没有则查找父元素）的字体尺寸计算的。比如
<div style="font-size:12px;text-indent:2em;background:red;">文本将缩进24px</div>
em的优势是，在改变字体尺寸的基数时，浏览器也会相应的调整后代元素大小。而且在IE6中也能使字体放大缩小功能起到作用。
劣势是要精确控制的话会相对困难。也有人提出是时候不用考虑基于字体大小（em）的设计了，主要是因为现在多数浏览器都已经有了更完善的页面缩放功能，对px同样有效。
用于设定字体尺寸时，和em的工作方式一样，更具体的差别还不太清楚。
通常情况下都喜欢先设定body {font-size:62.5%}，按照浏览器默认字体大小为16px的话，那么得到的字体大小就是10px，这样接下来的子元素就可以更方便的使用em计算，比如12px就可以使用1.2em来设定。
在行高中，就有这样的纯数字属性值，比如line-height:1.5，这就代表文本的行高是当前字体尺寸的1.5倍。比如当前字体是12px时，那么行高就是1.5*12px。
相对于px和%，纯数字值有个优势，举例如果body已经设定了行高为1.5，字体大小为16px，而子元素字体大小为12px，那么子元素行高就会先继承1.5的属性值，然后根据自身字体尺寸12px计算出他的行高为12*1.5。而不会像px和%会直接继承body已经计算出的行高。
原文：Efficiently Rendering CSS
翻译：如何使CSS渲染更高效
（为阅读更通顺，稍作了些修改）
我承认我并不经常想这样一个问题：我们写的css的效率如何，浏览器渲染速度又如何？这本应该是浏览器开发者应该关心的。Mozilla有一篇文章： about best practices 。 Google 当然也很关心这个问题，他们也有这样一篇文章：Optimize browser rendering 。
那么就让我们来了解下他们主要倡导的东东，然后讨论他们的实用性。
有一个很重要的原则，浏览器是从右往左读取你的css选择器。比如 ul > li a[title="home"] ，那么 a[title="home"] 将是最先被读取的。这一部分通常被称为目标选择器(key selector)的最后一部分，也是被选择的标签。
有四种目标选择器：ID, class, tag和通配符(Universal)。看下它们各自效率如何:
#main-navigation { } /* ID (最快) */ body.home #page-wrap { } /* ID */ .main-navigation { } /* Class */ ul li a.current { } /* Class */ ul { } /* Tag */ ul li a { } /* Tag */ * { } /* Universal (最慢) */ #content [title='home'] /* Universal */
根据从右往左和目标选择器的概念，我们可以知道下面这个选择器并不高效：
#main-nav > li { }
代码看着简单但实际没想象中的那么快，因为虽然浏览器可以通过ID迅速的找到 li。但实际上 li 标签是最先被读取的。
尽量不要写成这样：
ul#main-navigation { }
因为 ID’s 是唯一的，所以不需要用tag来限定，这只会让它更低效。可以的话，也不要在 class 上使用tag，虽然 class 不是唯一的，理论上你可以把它用在不同的tag。如果你愿意的话，你可以用tag控制不同的样式，这样你可能需要tag限定（比如：li.first），但这种情况很少，所以不要这么做。
David Hyatt:
后代选择器是CSS里最昂贵的选择器，昂贵得可怕——特别是当它放在tag和通配符后面时。
就如下面这个东东一样，绝对的效率毒瘤：
html body ul li a { }
我不是很确定是否有更好的证据去证明这一点，因为如果你有大量的选择器在CSS样式表里无法找到，这样的事情貌似很离奇，但一点必需注意的是，从右到左的解释一个选择器来说，一旦它找不到，那它就会停止尝试。然而如果它找到了，那它就需要花更多精力去解释了。
比如：
#main-navigation li a { font-family: Georgia, Serif; }
你可能不需要从 a 选择器开始（如果你只是想换个字体）。用下面这个可能更高效些：
#main-navigation { font-family: Georgia, Serif; }
不管怎样上面提到的东东都是有意义的，你可以按照上面的方法去做，因为它并不会限制你的CSS制作。但你也没必要太教条主义。如果你是个完美主义者，而之前又没有考虑过那东东，那是时候去重新看一下你之前写的一些样式是否有改进的地方了。如果你没发现你的网站明显的渲染缓慢，那大可别太在意，在以后的工作中多注意就行了。
我们知道ID’s 是最高效的选择器。当你想让渲染速度最高效时，你可能会给每个独立的标签配置一个ID，然后用这些ID写样式。那会超级快，也超级荒唐。这样的结果是语义极差，维护难到了极点。即使在核心部分你也不应该见过这样做的。我认为这个可以提醒我们不要为了高效的CSS放弃语义和可维护性。
顺便提一下，因为CSS选择器被很多javascript库使用，上面提到的东东仍然适用，ID选择器还是最快的，后代选择器和类似的东东相对会慢。
