首先我觉得，在分析prototype之前，应该先了解为什么要使用prototype来实现继承，而并不是把所有属性写到构造函数内部，那么这样做优势体现在哪里呢，如果你跟我有一样的困惑，请看如下两段代码：

在浏览器中分别执行两段代码，观察浏览器的内存占用情况（数据量比较大，等待脚本执行完毕，浏览器稳定后的数据），如下图：

从图片中的数据不难看出，在Firefox中，把所有属性全部写到构造的原型对象中，生成100000个实例对象时，占用内存会比把所有属性全部写到构造内部少15M，而在IE中，这个差距竟然达到97M，匪夷所思啊，神奇的IE。这也就是为什么写oo代码时，总是喜欢把类的一些属性和方法写到它的原型对象中，在达到同样目的的前提下节省内存的使用率，我想没有哪一个人愿意拒绝这样的做法。

缘何使用prototype会节省内存空间呢？我觉得有必要了解JavaScript中类的实例化过程。

通过这个实例化过程，可以看到，在每个实例化对象中，如果构造中属性全部放到原型对象中来实现继承（所谓的原型链继承），并不是拷贝原型中的全部属性到自身所占的空间内，而是通过__proto__来实现对F.prototype的引用，显而易见，这样做更能节省内存空间。

事实上，这个过程可以解释我们再开发中遇到的很多问题，比如，在构造内部定义的属性要比在原型中定义的属性优先级要高，正如上述代码片段，f.a =1而不是f.a=2，就是因为对原型对象的引用发生在对象初始化之前，详细见下图：

另外一个问题，修改原型对象中的属性或方法，即使在实例化之后，依然会奏效，这里需要注意的是，这个修改的过程需在F.prototype指向的原始对象上修改，不要试图将prototype重新指向一个新的对象，因为在实例化之后，在实例对象f中查找某个属性时，依然会从F.prototype指向的原始对象中查找，也就是说并不没有改变f.__proto__的指向，虽然我们期望看到他重新指向一个新的对象。

PS：说了很多，重点只有一个，就是深刻类的实例化过程，这才是JavaScript原型继承的本质。

从渲染的css上看，没有任何问题，百思不得其解，更为让我疑惑的是，在我同事的机器上，遮罩层的透明效果是有的，难道我RP有问题？太不可思议了。

既然问题出了，就要去想办法解决，没有任何回避的理由，经过一番细心的排查，发现我和同事的机器唯一的差别就在于装的操作系统不一样，他的是XP，而我机器上装的是WIN7。这可能就是问题的所在了，但是细想，WIN7不可能不支持filter-alpha-opacity的，这样的结论相信没有人相信，因为我看到我以前写的遮罩层组件是可以正常工作的，所以排除WIN7不支持alpha的可能，那么问题到底出在哪里呢，请看可以正常工作的遮罩层CSS：

如果你足够细心，我想应该会发现区别在哪儿，没错，就是高度不一样，一个是20000px（失效），一个是1801px（有效）。既然高度会影响filter的渲染，那么肯定会有一个临界点，事实证明，的确如我所料，在WIN7的环境中，如果元素的高度超过4096px，就一定会导致filter-alpha-opacity失效，而这一切在XP环境中并不会发生，真是验证了一句话，在MS的世界里，没有什么不可能！

拓展：在vista系统中，也存在相同的问题，元素高度的临界点为2048px。所谓标准浏览器（firefox、chrome、safari之流）中，opacity渲染的透明度是跨系统的，不会存在失效问题

PS：邪恶的WIN7，邪恶的IE，永远遭我BS.

设计起来当然不是什么问题，就是一个特殊的和服务器有通信的tab而已，在首轮tab切换过程中，发送一个XHR，然后再把Server响应的数据（基本上是html字串）塞到相应的容器中即可。这个过程中有个问题需要注意，在每个选项点击第一次之后，已经把所需要的数据加载到客户端，那么再次切换的时候就没有必要重新请求服务器了，这样做的依据就是判断内容容器中的innerHTML是否为空。

诚然，你如果真的反其道而行之，也并无过错，并不会影响网页功能的展现，但却是徒劳无益，反而加重服务器的负担，并且会影响到用户体验，这也就有被于使用ajax tab的初衷了。

同样的，详情请登录 ：Demo

先看一组数据:
0.1 + 0.11 = 0.21000000000000002
0.2 * 3 = 0.6000000000000001
0.7 / 10 = 0.06999999999999999

你相信吗？如果不信，那么立即打开firefox浏览器测试吧。有一点可以确信，你看到测试结果的表情，一定先是惊讶，后来是迷惑。

这里有几个demo，再来看看出现浮点数运算bug的概率，猛击之：加法、乘法、除法

对于这样的结果，我不知道是怎么产生的，但是既然是bug，就一定是可以hack的，思路很简单，先把所有的运算数转成int型（表达不准确，javascript的没有int、float之分），计算出两个运算数的小数点后的位数，再进行适当的运算，就可以得到原始的我们期望看到的结果了。代码如下：

加法运算：

乘法运算：

除法运算：

实现原理挺简单的，在此不在赘述，敬请猛击demo。

调用方法如下：

原文地址：http://www.uedmagazine.com/ued/comments.php?y=09&m=11&entry=entry091123-095015

事实上，捕获阶段是一个和冒泡阶段完全相反的过程，即事件由祖先元素向子元素传播，和一个石子儿从水面向水底下沉一样，要说明的是在IE，opera浏览器中，是不存在这个阶段的。从各浏览器提供的注册事件监听的方法中可见一斑，例如适用于ie,opera的attachEvent，有两个参数，attachEvent(”on”+type,fn)，而适用于所谓标准浏览器的addEventListener则有三个参数，addEventListener(type,fn,boolean)，前面两个参数不用解释，第三个参数boolean，就是决定注册事件发生在捕获阶段还是冒泡阶段，具体参考如下：

• true : 捕获阶段
• false : 冒泡阶段

话说，眼见为实，耳听为虚！那么好吧，请看demo，猛击这里

在这个demo中，注册事件监听默认发生在冒泡阶段，由于“元素a”，“元素b”和“元素c”有嵌套关系，为了更好的表现冒泡过程，所以请先点击“元素c”，会看到在各个浏览器中呈现的视觉效果是一致的，即事件是从c向a传播的，这也恰恰证明了所有浏览器都有冒泡这个过程的观点。经过上述的介绍，唯一让你感到吃惊的应该是，从视觉效果上，“元素c”并没有包含在“元素a”和“元素b”里面，而表现出来的效果确实证明”click”事件依次从c经过b传播到a的，反而包含“元素c”的“元素d”却没有响应click事件。事实上，这并不奇怪，因为事件冒泡和视觉上的布局结构是毫无关系的，这个冒泡过程仅仅依赖于dom元素的html结构（即嵌套关系）。效果见下图：

提及事件冒泡，那么不得不提“阻止事件冒泡”这个概念，因为我们最经常处理的任务就在于如何阻止事件的冒泡，来避免一些不必要的麻烦，关于这点，由于在之前的文章中单独讨论过，在此不再赘述，详见：阻止事件冒泡

言归正传，为了更好的看到捕获和冒泡的区别，那么这时候需要你把这个demo另存到本地，然后找到如下图所示的代码片段：

接下来，你要做的就是，把这个代码片段中false改为true，也就是说让注册事件监听在捕获阶段进行，依次ctrl+s，在各个浏览器中打开这个页面，细心的你会发现，在firefox,chrome,safari中表现效果发生了变化（IE，opera中无变化，因为不存在捕获阶段），如下图：

对比两张图片所显示的视觉效果，应该足以证明本文开头所提出的观点了，如果针对事件捕获和冒泡尚有任何疑问或不解，请留言或者Email我，交流研究！

事实上，如果这么做，fn2会把fn1覆盖，也就是说在单击obj时只会执行fn2中的代码片段，fn1则会被忽略，很显然这样不能满足我们的需求。在考虑到这个问题的时候，JS已经为我们准备了像attachEvnet、addEventListener这样的方法来满足我们的需求，虽然在不同级别的浏览器中方法不尽相同，利用对browser的能力检测还是可以轻松的实现一个兼容的方法：

这样目的就达到了，当单击obj时，依次执行fn1、fn2。解决了这个问题后，细心的淫们会发现在执行的function中this执行是有问题的，始终指向window，又不是一个不小的麻烦。那么有没有办法，来解决这个棘手的问题呢，答案是肯定的，这正是我写这篇文章的意义所在，废话!
其实只需对bindEvent稍作加工即可，如下：

理论上，这样的解决方案近乎完美了，但是还有一个问题亟待解决，因为在attachEvent中使用了匿名函数来执行fn，导致在无法使用detachEvent来删除绑定的某个代码片段，也许obj["on"+type] = null可以解决，清空绑定的代码片段，这很粗暴邪恶，同时也违背我们的业务需求。

我想要从根本上解决这些问题，就一定抛弃attachEvent这个方法，事实上我也是这样做的，如下：

这段代码有点饶人，首先根据type类型给elem注册一个相关的属性_type，来存放elem同种类型事件要执行的代码片段，当然在这个过程中要先判断这个属性是否已经存在，如果存在，则跳过这一步。然后要遍历这个存放代码片段的数组，判断是否有和要添加的代码片段相同的代码片段，如果有，直接跳出function。假设在上一步条件不满足的情况下（即代码片段不重复），那么把这个代码片段push到相应的数组中。之后干的事情，我想大家应该很清楚了，没错，就是把相应数组里的代码片段依次apply到elem下执行。当然，这个过程只有在触发事件的时候，才会发生。

依照这个原理，那么要删除绑定的某个代码片段就很容易做到了，只需要从elem["_"+type]这个数组中把相应的代码片段删除即可。

解释一下为什么这个存放需要绑定代码片段的数组设置为elem的一个属性，其实理由很简单，就是不用声明一个全部变量（数组类型），来管理这个二维的数据结构，这样可以保证bindEvent,removeEvent的高度独立性。

最后，希望各位大淫能帮忙测试一下这两个方法的健壮性如何，是否还存在一些bug，如果有，提交给我，zhenn不胜感激之至！

没有实践就没有发言权，demo如下：

执行如上代码，事实上只执行了test(1)和test(4)，原理如上所述。

a&&test(1)这种运算，其实我不知道是否有个专业的名词去描述它，在javascript森林群ToFishes同学称之为“惰性运算”，那么暂且叫它“惰性运算”吧，实际上相当于if(a){test(1)}。

其中||运算符，有个很重要的应用就是给function的参数设置默认值，如：

以上内容，针对刚入门javascript的童鞋们，大湿级的淫们可以直接skip.

在JavaScript中，除了Object,Array是地址引用，其他数据类型，诸如Number
、Boolean、String等都是值引用，这就是从陷阱中挖出的东西，同一个坑不能跳进去两次啊！杯具…