1. window.onload 事件在所有页面元素（包括图片，脚本等）都下载完毕后才会触发。
2. 除了 IE，其它浏览器支持 DOMContentLoaded 事件。当 DOM 内容下载完毕，就会立刻触发。
3. 事件处理器必须在事件触发前注册才有效，否则不会被执行。例子：在 window 已经 load 完成后，再给 window.onload 注册的处理器不会被执行。
4. 针对 IE，有各种模拟 DOMContentLoaded 事件的办法。目前被广泛采纳的方案是判断 document 是否可以滚动（doScroll）。一旦可以滚动，就意味着 DOM Content 已经加载完毕。

下面说两个陷阱：

1. 在 setTimeout 里给 window.onload 添加处理器。这是不可靠的，无法保证添加的处理器一定会执行。是否执行取决于 setTimeout 的延时和页面内容的加载时间。比如：

   // Test 1. 在 onload 后添加 onload handler
   setTimeout(function() {
       onLoad(function() {
           alert('Test 1: window loaded.'); // 不一定执行
       });
   }, 20);
   

2. 在动态加载的 script 的 onload 事件里，给 window.DOMContentLoaded 添加处理器。这更不可靠，除了 IE，其它浏览器下根本不会执行。比如：

   // Test 2. 测试动态添加 script
   getScript('http://jqueryjs.googlecode.com/files/jquery-1.3.2.min.js', function() {
      alert('Test 2: jQuery loaded.');
       onReady(function() { alert('Test 2: content loaded.'); }); // 不可靠
   });
   

测试页面：load_test.html

最后提一点：从上面的测试页面中可以看出，IE 下模拟 DOMContentLoaded 事件仅仅是模拟，和其它浏览器依旧存在本质上的差异。在 IE 真正原生支持 DOMContentLoaded 前，疯狂使用$(document).ready(...), YAHOO.util.Event.onDOMReady(...)等方法时，依旧需要谨慎，要留意陷阱。

结论：

1. Safari 和 Opera 是两个极端，一个完全还原，一个完全保留。
2. Firefox 下最简单的办法是设置 autocomplete = ‘off’ 属性。
3. IE 必须在 setTimeout 中还原表单值才有效。
4. Chrome 除了不支持 onpageshow, 其它表现和 Firefox 一致。

最后胜出的是：

'v' == '\v' && setTimeout(function() {
    // reset code
}, 0);

同时在 html 中，将要还原的表单元素加上 autocomplete = ‘off’ 属性。
最后，忘掉 Opera.

结论：

1. IE下，父级容器只接收自身也有的冒泡事件。
2. IE下，某些事件类型，比如propertychange，不会产生冒泡。
3. IE下，移除自身的事件，冒泡会被终止。
4. 上一条的解决办法是，将移除自身的操作放在setTimeout里，排队到线程后面。
5. IE里，setTimeout会改变执行环境，比如Event.getTarget(ev)放在里面将导致错误。
6. 将Event.getTarget(ev)放在setTimeout外面，则一切ok.

总之，IE下，采用父级容器来代理捕捉冒泡事件时，要小心谨慎，多加测试。
附加一点小感慨：阻止链接a的默认事件时，用preventDefault足矣，stopEvent会对之后的扩展带来麻烦。

对于事件代理，可以参阅这篇文章：JavaScript事件代理比你想象中的简单
对于setTimeout，可以看看这篇心得：对How JavaScript Timers Work的理解

总结如下：

• JavaScript engines only have a single thread, forcing asynchronous events to queue waiting for execution.
• setTimeout and setInterval are fundamentally different in how they execute asynchronous code.
• If a timer is blocked from immediately executing it will be delayed until the next possible point of execution (which will be longer than the desired delay).
• Intervals may execute back-to-back with no delay if they take long enough to execute (longer than the specified delay).

我的心得：

1. 无论是setTimeout还是setInterval，触发时，如果当前进程不为空，都得去排队等待执行，这一点上是无差异的。
2. 区别是，setTimeout只需排一次队，setInterval则需要按照预设的间隔时间，每到时间点都去排一下。
3. setInterval去排队时，如果发现自己还在队列中未执行，则会被drop掉。也就是说，同一个inerval，在队列里只会有一个。
4. 因为队列机制，无论是setTimeout还是setInterval，第一次触发时的时间，只会等于大于预设时间，不可能小于。
5. 对于setInterval来说，如果执行时间大于预设间隔时间，很可能导致连续执行，中间没有时间间隔，这是很糟糕的，很可能会耗费大量cpu.

因此，对于动画来说，如果单帧的执行时间大于间隔时间，用setTimeout比用setInterval更保险。John Resig在回复中也表明了这个观点：

It really depends on the situation – and how the timers are actually being used. setInterval will, most likely, get you more ‘frames’ in the animation but will certainly tax your processor more. A lot of frameworks end up using setTimeout since it degrades more gracefully on slower computers.

一个简单的测试页面：timer_test.html（请在Chrome下运行，注意那些零值或接近零的值，setInterval没有interval了！）

因此，在这种情况下，采用setTimeout更保险：

setTimeout(function(){
    /* Some long block of code... */
    setTimeout(arguments.callee, 10);
  }, 10);

当然，大部分情况下，单帧执行时间都小于预设的间隔时间，上面分析的差异，是感觉不大出来的。