岁月如歌

在正常情况下：

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

下面说两个陷阱 阅读全文 »

测试页面：no_autocomplete_test.html

结论：

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.

请先看测试页面：event_bubbling_test.html

结论：

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的理解

John Resig在How JavaScript Timers Work一文中，对setTimeout和setInterval的分析很精辟：

总结如下：

• 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).

我的心得： 阅读全文 »