两矩形区域相交

在写随机展示的一个模块时,需要判断随机生成的区域与原有区域是否相交

最初想到的方法是：

算法一：如果一个区域有一点在另一区域中，那么两个区域一定相交

js实现代码：

// 判断点在矩形内
function _inRegion(point, region) {

    return point[0] < region.right && point[0] > region.left
        && point[1] < region.top && point[1] > region.bottom;

}
// 判断矩形1是否有点在矩形2中
function _isCross(region1, region2) {

    return  _inRegion([region1.left,region1.top], region2) ||
        _inRegion([region1.right,region1.top], region2) ||
        _inRegion([region1.right,region1.bottom], region2) ||
        _inRegion([region1.left,region1.bottom], region2);

}

function isCross(region1, region2) {

    return _isCross(region1, region2) || _isCross(region2, region1);

}

看到上面的代码觉得实现太麻烦了吧，再来看一种算法：

算法二：如果两个矩形相交，则必然存在线条交叉，而能交叉的线条只有横线和竖线，两根横线或两根竖线都不可能交叉。所以，这个问题就转化成寻找是否存在交叉的横线与竖线。

实现代码：

// 判断横线1是否与竖线2相交
function _crossLine(line1, line2) {
    return line1.from[1] < line2.from[1] && line1.to[1] > line2.to[1] &&
        line1.from[0] < line2.from[0] && line1.to[0] > line2.to[0];
}
//判断矩形1横线是否与矩形2竖线相交
function _isCross(r1, r2) {
    return _crossLine({from:[r1.left,r1.top],to:[r1.right,r1.top]},
        {from:[r2.left,r2.top],to:[r2.left,r2.bottom]}) ||
        _crossLine({from:[r1.left,r1.bottom],to:[r1.right,r1.bottom]},
            {from:[r2.left,r2.top],to:[r2.left,r2.bottom]}) ||
        _crossLine({from:[r1.left,r1.top],to:[r1.right,r1.top]},
            {from:[r2.right,r2.top],to:[r2.right,r2.bottom]}) ||
        _crossLine({from:[r1.left,r1.bottom],to:[r1.right,r1.bottom]},
            {from:[r2.right,r2.top],to:[r2.right,r2.bottom]});
}
function isCross(region1, region2) {
    return _isCross(region1, region2) || _isCross(region2, region1);
}

这种看起来也不简单，但至少是一种思路，还有其他算法吗？有

算法三：如果两个矩形相交，相交区域一定是个点或者矩形

实现代码：

function isCross(region1, region2) {
    var left = Math.max(region1.left, region2.left),
        right = Math.min(region1.right, region2.right),
        top = Math.min(region1.top, region2.top),
        bottom = Math.max(region.bottom, region.bottom);
    return left < right && bottom < top;
}

我靠，代码瞬间减少了很多，再看一种算法：

算法四：如果矩形1的一边距离到矩形2对应边的距离小于等于矩形1的宽度或高度 =>两矩形相交

实现代码：

function isCross(region1, region2) {
    return (region2.left > region1.left &&
            region2.left - region1.left < region1.right - reigon1.left) ||
        (region2.top > region1.top &&
            region2.top - region1.top < region2.top - region2.bottom) ||
        (region1.left > region2.left &&
            region1.left - region2.left < region2.right - reigon2.left) ||
        (region1.top > region2.top &&
            region1.top - region2.top < region1.top - region1.bottom);
}

貌似代码有优化的空间，先不管，考虑还有没有更简练的算法？

算法五：如果一个矩形在另一矩形所形成的四个区间外 <=> 两个矩形不想交

实现代码：

function isCross(region1, region2) {
    return !(region1.left > region2.right || region1.right<region2.left||
        region1.bottom > region2.top || region1.top < region2.bottom);
}

看到这种算法时，我震惊了，无论从代码量还是性能上都优于上面的算法，当然如果需要获取相交区域，算法3更好。

回头看看上面5种算法，从不同的角度出发得到不同的算法：算法1从点的角度触发，算法2从线的角度，
算法3从区域的角度，算法4从一维距离角度，算法5从区间的角度；思量一下，前4种算法都是正向思维，第5种逆向思维；
逆向思维，也许自己太多过程式编程脑子秀逗了，好的算法醍醐灌顶。

结束，下一篇关于如何判断两个线段是否相交，你如何实现？

1.selection.clear file表单 导致form 无法 submit

demo

第一次点击提交按钮无法提交表单
说明：ie浏览器不允许直接通过value=“”方式情空文件控件，所以尝试使用selection.clear清除，就会引发这个问题

解决方法：使用form的原生reset清空

2.selection.emtpy 触发 window.blur

demo

选择一段文字后，在空白处点击，浏览器默认清除选择，触发window blur

说明：ie8-以下才会这样，ie9其他标准浏览器都不触发；显示调用 selection.empty方法，及浏览器默认改变选择都触发

解决方法：mousedown中延时注册blur，因为是在mousedown 之后触发的，通过延时注册，让其先触发

要实现拖放，基本思路就是：鼠标点下时监听移动，抬起时停止监听。

        var x,y;
        function move(e) {
            el.style.left = e.clientX - x + 'px';
            el.style.top =  e.clientY - y + 'px';
        }

        function stop() {
            E.detach(document, 'mousemove', move);
            E.detach(document, 'mouseup', stop);
        }
        E.on(el, 'mousedown', function(e) {

            x = e.clientX - el.offsetLeft;
            y = e.clientY - el.offsetTop;
            E.on(document, 'mousemove', move);
            E.on(document, 'mouseup', stop);

        });

这样拖放就实现了，当然还有一些问题：

拖放禁止

1.当第一次拖放后，再次拖放元素就会发现会出现拖放禁止图标，是因为第一次拖放时点击拖放元素，拖放元素被选择，第二次拖放时使用了浏览器默认拖放。浏览器对于 image，link，selection默认是可以拖放的。

2.拖放过程中移动到其他元素时，其他元素被选择，再次拖放也会出现拖放禁止图标，原因同上。

解决这个问题:

方法一：preventDefault

问题1，在mousedown中阻止默认动作，防止元素被选择；问题2，在mousemove中阻止默认动作，防止其他元素被选择(opera貌似无效)。

这个方法有点体验不足：在ie9，ff等现代浏览器将 “清除之前选择”的默认动作也阻止了，如果之前有选择内容，拖放时原选择不会被清除。

方法二：清空 selection

mousedown,mousemove的时候清空一下selection即可解决上面两个问题

有的程序也通过setCapture来阻止默认事件，并且扩大捕获，兼容性不好不考虑；

综合考虑，采用清空selection比较好。

异常终止问题

1.窗口失去焦点时（如：alt+tab切换，alert等），无法触发mouseup（chrome 可以触发），导致拖放不终止，回到窗口时继续拖放，体验不好

2.页面中存在iframe时，鼠标移动到iframe中事件传递到iframe的document中，无法到达原来的document导致无法触发mouseup，mousemove等

解决第一个问题，可以监听下window blur事件，终止拖放；但这里有个问题：ie通过document.selection.empty()方法清除selection，当selection有内容时，导致window触发blur事件，拖放终止。这个触发是在mousedown处理完之后触发的，即window blur注册之后再触发，解决可以考虑setTimeout延时注册下。

解决第二个问题，考虑将事件仍传递到本页面document，可以建个遮罩层将iframe遮挡(为了简洁，这里不实现)。

这样简单的拖放程序就出来了，demo，code：

function Drag(el) {
    this.el = el;
    this._initEvents();
}

Drag.prototype = {
    moveTo : function(x, y) {
        var el = this.el;
        el.style.left = x + 'px';
        el.style.top = y + 'px';
    },
    _initEvents : function() {

        var x,y,self = this,el = this.el;

        function move(e) {
            // 防止移动过程中选择其他元素，保证体验一致
            util.clearSelection();
            self.moveTo(e.clientX - x, e.clientY - y);
        }

        function stop() {
            E.detach(document, 'mousemove', move);
            E.detach(document, 'mouseup', stop);
            E.detach(window, 'blur', stop);
        }

        E.on(this.el, 'mousedown', function(e) {

            // 清除之前选择，防止拖拽时禁止
            util.clearSelection();

            var style = util.getComputeStyle(el);
            x = e.clientX - el.offsetLeft + (parseInt(style.marginLeft) || 0);
            y = e.clientY - el.offsetTop + (parseInt(style.marginTop) || 0);

            E.on(document, 'mousemove', move);
            E.on(document, 'mouseup', stop);
            // 失去焦点时终止   document.selection.empty() 会触发blur，延时注册
            setTimeout(function(){E.on(window, 'blur', stop);},0);
        });
    }
};

如果要做成组件，当然还需要考虑全面一些，如：iframe情况，移动范围，非绝对定位元素，移动元素和控制元素不同，相关事件支持等等。现在回头看看实现不复杂，只是遇到问题时自己跑偏了，之前看过《JavaScript 拖放效果》这篇文章，觉得很多问题需要处理，然后写的时候遇到问题就去看文中的介绍，而并没真正从问题本身和解决方法上入手，结果严重影响了效率，而且弄的晕头转向，不知在为了解决什么问题而加代码。有参考固然是好的，但是需要更多的独立思考，理清思路，关注本质，这样程序才能得心应手，才是自己的程序。

字符集、编码字符集、字符编码

字符集

字符集就是一些字符的集合，比如我们使用的中文就可以看成一种字符集

编码字符集

是指每个字符都有唯一数字与之对应的字符集，每个单元编码字符被称作码点。码点的值表示着字符所在字符集中的位置，这样我们就可以通过具体的数字根据编码字符集找到相应的字符。

字符编码

字符编码表示这编码字符集码点值如何被映射成计算机中的字节。对于编码字符集，虽然对每个字符有了唯一的索引，但是要表示在计算机中，必须以字节的形式表示，而字符编码，正是表示这一映射过程。这样计算机就可以跟进字节和码点值的映射关系跟进字符集找到相应的字符。当然我们可以简单的将码点值直接转换成对应的计算机字节，码点值是65在计算机中也用65表示，这种编码方式最简单，ISO 8859系列字符集就是采用这种编码方式；但是为了优化之一映射过程还有其他编码方式，同一编码字符集也可以有多种编码方式，比如我们熟悉的Unicode字符集，就有UTF-8, UTF-16, and UTF-32编码方式，不同编码方式映射到计算机表示的字节就有可能不同。

字符编码就是计算机找到对应字符的钥匙，钥匙指定错了，计算机找到字符也就不正确了，这就是我们遇到乱码的原因。

在web中又是如何指定字符编码的呢？我们再来看下HTTP Header中关于字符的几个字段：

HTTP Header

Accept-Charset

Accept-Charset 字段表示可以响应采用哪些字符集编码是可以接受。服务器可以跟据这个字段了解客户端接受字符集的能力。当服务器不能提供相应字符集编码的数据时，就会返回406状态码，或者一个unacceptable response。这个字段平常打交道比较少，再看另一个非常重要的字段：

Content-Type

content-type字段标识着响应正文的media-type，已经采用的字符集编码。charset非常重要，因为接收端正是根据这一信息来对响应正文进行解码。设置一个和文档实际编码一致的charset就可以保证接受端能够正确的解码，也就是不会出现乱码。另外，需要注意的是，在html，css中这一参数声明会覆盖文档内的字符编码声明。

好了，了解了这些基本知识，我们具体看看html中设置编码问题：

HTML

html中我们可以通过meta 标签设置文档字符编码如：<meta charset=”gbk”/>,浏览器确定文档编码的过程简化说是这样的^[1]：

1. 如果用户在客户端明确指定了字符编码，客户端可以确定编码，停止检测（这一步可选）
2. 如果http header指定字符编码，客户端确定编码，停止检测(正如上面所说，content-type charset会覆盖文档内的字符声明)
3. 客户端查找文件编码信息meta charset/http-equiv/content，如果找到确定编码为相应值，停止解析
4. 最终如果无法确定编码，使用用户的默认编码,用户默认字符编码和本地语言相关，如中文语言默认编码使用GB18030

所以指定content-type或者meta charset情况下，并且和文件本身编码一致，浏览器就可以解析出正确字符。如果没用明确指定字符编码，就会产生乱码的风险，虽然浏览器也做了一些检测工作。

html文件中编码我们一般不会遇到乱码，再来看看比较常见的外链css/script中确定编码的过程：

css/script

外链css文件可以在文件开始设置@charset “charset”来指定字符编码，外链script可以设置script标签的charset属性指定字符编码，script具体确定过程是这样的^[2]：

1. 如果content-type指定，使用相应编码，停止检测
2. 如果charset属性指定，使用相应编码，停止检测
3. 最终如果无法确定编码使用当前文档的编码作为文件编码

css应该和script确定过程大致相同，一般情况下我们保证外链样式编码和文档一致即可或者手动设置@charset，script在动态请求时遇到乱码的情况会比较常见，尤其在请求内容不可控的情况下，如果响应方没用指定content-type，需要手动设置动态创建script的charset属性

再来看看最常见乱码的情况ajax中编码：

xmlHttpRequest

xhr请求数据并解析响应，在发送数据和接受数据时都可能会遇到乱码的问题，分开看一下：

send(data)

首先xhr提供了setRequestHeader方法，我们可以设定请求头，因此可以设定content-type,发送数据字符编码过程[3]：

1. 如果data是 document，mime将使用application/xml;charset=文档的编码
2. 如果data是 string，将会对字符转码成utf8，mime使用 “text/plain;charset=UTF-8“
3. 如果通过setRequestHeader设置了mime，那么charset参数会被设成utf-8，type保留，否则使用前面的mime type

可见发送数据，xhr保证了字符编码和实际编码一致（都为utf-8），这样接收端可以正确的解析字符，接收端出现乱码一般都没用按照正确的编码解析，或者又按另一种编码输出，而没有转换编码

Response

首先说下xhr的overrideMineType方法，允许覆盖相应的mine type，（目前仅ff，chrome支持），接收数据的编码大致^[3]：

1. 采用 overideMineType设置的编码 ，结束
2. 如果响应设置了Content-Type 采用对应编码，结束
3. 如果mine type是 text/html 采用 html的编码确定方式
4. 采用UTF-8

由于overideMineType兼容性问题，让服务端输出正确的content-type是比较简单有效的方法，当然还有其他一下方法，这里不讨论了

总结

保证设定的字符编码和文件真实编码一致，即可保证计算机解析出正确的字符；这也是产生乱码问题的根源；设定http content-type 即可指定数据的编码，客户端确定编码的优先级最高；如果没用设置content-type，对于html、css、script都有相应的指定编码的方式，对于xhr，发送的数据总是以utf-8编码，发送与实际字符编码一致（和文档编码无关），接收数据如果没用指定content-type，“最终”会以utf-8处理。总之，必须指定文件真实编码一致的字符编码，来保证计算机能够正确识别字符，避免乱码。

其他一些参考：

W3C处理html字符编码的文章： http://www.w3.org/International/tutorials/tutorial-char-enc/
overideMineType兼容方案：http://www.cnblogs.com/cuixiping/archive/2008/03/22/1118226.html

注1：具体步骤参见：http://dev.w3.org/html5/spec/parsing.html#determining-the-character-encoding
注2：具体步骤参见http://dev.w3.org/html5/spec/scripting-1.html#the-script-block-s-source
注3：具体步骤参见http://www.w3.org/TR/XMLHttpRequest/

var a =1;
function fn(){alert(a);}
var b = a++ + fn();

alert出的值是是怎么呢？

按照我之前的认识应该是 1,()优先级最高最先被执行此时a=1，可事实在各个浏览器都是 2

不得不怀疑之前的认识

又测试了下其他语言， php，java也都一样的结果：2，c和c++输出：1

参考了下犀牛书还有语言的官方，基本都表述：运算符优先级决定被运算的顺序，像MDN：“Operator precedence determines the order in which operators are evaluated”，但 PHP ：“The precedence of an operator specifies how “tightly” it binds two expressions together”。

按php的说法就很好理解上面的问题了，优先级表示着运算符结合能力的强弱

但是真是那些说 “evaluate order”的错了？？？咨询了好几个同事，终于算是有个自己满意的解释

表达式的运算顺序和运算符优先级根本是两个概念：运算符的优先级只表示着对于运算时哪个运算符先被结合（也可以说执行），至于怎么个顺序运算和它无关，而表达式的运算顺序和各个语言的规范有关，比如java中就明确定义evaluate order：Left To Right，看了下JS的ECAM规范，虽然没用像java那么明确说明运算顺序，但是跟据各个运算符的运算顺序可以看出也是 从左向右 运算的（包括函数调用，参数计算）。

上面 b = a++ + fn()运算过程：

1.运算b是个ref
2.运算=右边部分，a++，此时a=2
3.运算fn()

具体过程可以这样理解：

1.扫描到=操作符，先运算b
2.扫描到++(尽可能多的结合)，后面是+，++的优先级高于+，运算a++，此时a++会产生副作用（a+=1）,js会先算完子表达式再执行，a=2
3.接着扫描到()执行函数运算

C语言又怎吗输出1呢？

C语言可能为了编译器可以灵活的优化程序，并没用明确确定运算顺序以及副作用处理，所以不同编译器运算结果也可能不同，比如：

int i =1;
int m = (i++) +(i++)+(i++)

有的编译器是6，有的编译器(MSC,TurboC)编译出来是3；还有函数实参运算顺序的问题也一样。

总之：

表达式的运算顺序由语言规范定义和运算符的优先级“无关”，运算符的优先级及结合性只在运算时判断那个运算符先被运算（这样说，MDN的解释也没错只是自己理解错了），更好理解些优先级结合性表示运算符谁先被结合使用;Javascript中 跟据ECAM中对各个操作符的运算顺序的规范，Javascript的运算顺序应该是：从左到右，副作用运算先执行再继续表达式运算(不知有没有特例，没看到明确说明,-_-)

相关的讨论：

JavaEye关于java和c运算顺序的问答：http://www.iteye.com/problems/20258
StackOverflow Javascript运算顺序的讨论： http://stackoverflow.com/questions/5944593/javascript-evaluation-order
一篇讨论c#，java,c运算顺序的blog：http://rednaxelafx.iteye.com/blog/132187 //added 2011-07-13

var a = function() {},
    b = new a();
Function.prototype.isPrototypeOf(a);
Object.prototype.isPrototypeOf(a);
Object.prototype.isPrototypeOf(b);
Function.prototype.isPrototypeOf(b);
Object.prototype.isPrototypeOf(Function);
Function.prototype.isPrototypeOf(Object);
Object.constructor === Function;
Function.constructor === Function;

上面3-10行各返回的是true还是false？答案

如果你都想对了，就别浪费时间继续看了-_-

理解上面的问题，就要搞清谁是原型链的顶级及继承关系,参考ECMA5规范：

“The value of the [[Prototype]] internal property of the Object prototype object is null, the value of the [[Class]]internal property is “Object”, and the initial value of the [[Extensible]] internal property is true.”

“The Function prototype object is itself a Function object (its [[Class]] is  “Function”) that, when invoked,accepts any arguments and returns undefined.The value of the [[Prototype]] internal property of the Function prototype object is the standard built-in Object prototype object (15.2.4). The initial value of the [[Extensible]] internal property of the Function prototype object is true.”

Object prototype object 标准内置对象（这里简称OPO） 是所有原型链的鼻祖，再向上就是null了
Function prototype object 标准内置对象（这里简成FPO） 是函数的原型对象，其__proto__为OPO

Function prototype及__proto__都指向FPO
所有其他内置构造函数其__proto__为FPO，prototype指向OPO，如：Object 构造函数 __proto__指向内置FPO，prototype指向OPO

函数实例也是一个实例对象（通过 new Function而来），和Object一样，内部prototype指向构造函数的protype属性，即FPO，prototype属性是创建时被添加（为OPO）用来作为构造函数而创建的 。

说的比较乱，画张图：

Function 用于实例函数对象，其prototype 为FPO，这样保证所有其他函数的继承FPO的属性方法
其他函数 用于实例普通对象，其prototype为OPO，保证每个对象实现都继承OPO的属性方法。

再来看看代码中用到的isPrototypeOf方法：

isPrototypeOf方法

O.isPrototypeOf(V)方法用于检查V的构造函数的原型是不是O，根据ECMA5规范

Object.prototype.isPrototypeOf (V)
When the isPrototypeOf method is called with argument V, the following steps are taken:
1.  If V is not an object, return false.
2.  Let O be the result of calling ToObject passing the this value as the argument.
3.  Repeat
    a.  Let V be the value of the [[Prototype]] internal property of V.
    b.  if V is null, return false
    c.  If O and V refer to the same object, return true.

在检查时会有个向上遍历的过程，即：检测V的构造函数的原型是不是O，如果不是，接着检查V的构造函数的原型 的 构造函数原型 是不是O，直至原型为null，返回false。

理解了上面，再来看看开始的那段代码：

var a = function() {},
    b = new a();
Function.prototype.isPrototypeOf(a); // a的__proto__为 FPO，返回true
Object.prototype.isPrototypeOf(a); // a的__proto__为 FPO，向上查找，FPO的 __proto__ === Object.prototype,返回true
Object.prototype.isPrototypeOf(b); // b的__proto__为OPO，返回true
Function.prototype.isPrototypeOf(b); // b的__proto__为OPO，向上查找，OPO的__proto__为null，返回false
Function.prototype.isPrototypeOf(Object); // F的__proto__为FPO,返回true
Object.prototype.isPrototypeOf(Function); // F的__proto__为FPO，向上查找，FPO的 __proto__ === Object.prototype,返回true
Object.constructor === Function; // true
Function.constructor === Function; // true

讨论之前，首先需要理解的是js的单线程机制，即在同一时刻js只能执行一个任务，另外实际上浏览器的渲染也和js共用同一线程，这就意味着js在处理代码时浏览器会停止解析，如图所示：

当遇到js代码时js引擎会解析执行代码，此时浏览器渲染停止，直到脚本解析完毕才继续。当脚本执行耗时过长，尤其当引入外部脚本时加上脚本的加载时间，对ui渲染的阻塞更为严重，这是性能优化的一个方面，也是这篇文章为什么讨论脚本加载执行顺序的主要原因。

两种嵌入方式

解析嵌入（Parser-inserted）

指在html源代码中通过<script src=”XXX”>等方式引入（术语上这类脚本成为 Parser-inserted script），这种方式下浏览器会以<script>标签在页面中出现的顺序加载和执行，即同步加载执行。正如前面讨论的，这种方式会阻塞页面其他元素的加载，及页面渲染。

脚本嵌入（script-inserted）

通过脚本动态载入方式（术语上这类脚本成为Parser-inserted script），动态载入脚本的方式有很多中如：document.write,xhr eval,script document Element等^[1]，其中通过动态创建script标签是被广泛应用推荐的一种，这里只讨论这种情况。

通过动态创建script元素可以实现无阻塞加载，但这意味着什么？一个脚本阻塞是从开始加载到执行完毕才结束，大体有三个步骤：

1. 加载脚本
2. 解析
3. 执行

在这个过程中通常#1耗时最长，通过这种方式意味着不必等待脚本的#1(也许还有#2)过程，浏览器ui线程可以不受干扰继续执行，但是由于js单线程机制对于#3过程无可避免的会对ui线程阻塞。当然，浏览器解析通常很快的（尤其是新的js引擎），通常这部分影响几乎察觉的到，但是如果脚本性能不好，执行需要较长时间这也会产成性能瓶颈。

总之，无阻塞加载使浏览器不必等待脚本加载而继续渲染，两者异步执行，但脚本执行仍会阻塞渲染。

并行加载

根据上面的无阻塞方式加载多个脚本文件，这些文件是并行加载的，这样相对传统方式带来的好处是，使浏览器更快更早的请求文件并且不会阻塞浏览器渲染，但是这里仅仅是并行“加载”，并不意味着会并行执行，还是那个原因js是单线程的，同一时间只有一个js会被执行！另外带来的一个问题是，脚本并行加载其执行顺序又是怎样的呢？

对于脚本的执行顺序，目前各个浏览器执行情况还有些差异：

1.opera and firefox3.6-

执行的顺序会按照脚本被动态插入的顺序执行

2.ie，Safari，chorme and firefox4^[2]

脚本加载完毕即会执行，不会保持他们被插入的顺序

浏览器的努力：defer & async

对于无阻塞脚本加载，浏览器也给出了一定的方案，包括早期ie实现（后来被firefox3.1引入）的defer属性以及HTML5定义的async属性

defer

脚本下载不会阻塞浏览器渲染，直到文档解析完成时才会执行，DOMContentLoaded触发之前（兼容性不好）。

async

这个属性由html5新引入的标准属性，这是个布尔属性，当被定义时，脚本会无阻塞加载，脚本文件加载完成立即执行（不顾及脚本出现的先后顺序），如果需要脚本保持引入的先后顺序需要显示的设置.async = false(对于script-created 脚本默认为true，目前仅firefox4支持false)。

开发者的努力：LABjs

labjs项目主要特性能够实现脚本并行加载和顺序执行，已经被多个大型网站采用，看个例子：

   $LAB
   .script("a1.js").wait()
   .script("a2.js")
   .script("a3.js").wait()
   .script("a4.js");

这样,a1a2a3a4脚本会被并行加载，但是执行顺序还是会按照a1->a2a3||a3a2->a4的顺序执行。由于前面提到的对于动态创建script元素，不同浏览器两种不同的执行顺序，其实现进行了browser sniff：opera and old firefox直接动态插入即可保证执行顺序；对于IE chrome sarfari方面通过一个trick： 预加载script文件（通过设置script type为不能识别的值，保证浏览器只加载不执行），然后按照需要的顺序插入正确的script元素，这些元素就会立刻执行并且保持顺序：

当然，还有许多其他项目的实现如 requireJS 的order pluigin，HeadJS ，ControlJS…

总结

由于javascript及ui render的单线程机制，采用无阻塞加载脚本来提高页面性能，同时看到浏览器及开发者对于这方面的努力及实现，但请注意无阻塞加载仅仅是“加载”而已，执行过程仍然会阻塞渲染，进一步的优化需要我们回归到代码本身，减少其执行时间，以获得更快的响应。

注：

1. Steve提出了各种实现方式 loading scripts without blocking
2. firefox4 pre7之前仍是按照原来的方式顺序执行，为了符合html5的规范改为无序执行，这里还有labjs的作者和火狐开发者的一个故事，最终firefox4通过设置async=false来保持这种执行顺序。

参考：

• http://www.whatwg.org/specs/web-apps/current-work/#the-script-element
• http://www.nczonline.net/blog/2010/08/10/what-is-a-non-blocking-script/
• https://developer.mozilla.org/En/HTML/Element/Script

Update：

1. 添加defer脚本执行的确切时间 2011-05-24

小谢的一个想法，觉得挺实用，就写了下火狐版的扩展

“
不知从何时开始，cnBeta上的评论有了48小时的保鲜期，过了48小时，任何曾停留在页面上的喧嚣，都会消隐不见。cnBeta月光宝盒——轻轻一点，昨日重现（甚至都不用点）。
”

firefox扩展地址：https://addons.mozilla.org/zh-CN/firefox/addon/cnbeta_yueguangbaohe/

Chrome扩展地址：https://chrome.google.com/extensions/detail/nkgjnkanhkhlallldojlbekikmeefcje

if u like,try!

原来就有接触，因为字体问题，遂放弃，这次研究了下，终于解决，netbeans 乱码一般有两种情况：

1. 菜单界面乱码
2. 文件内容乱码

下面是解决方法：

一、菜单界面乱码：

很容易解决，找到{Netbeans安装目录}/etc/netbeans.conf文件，在netbeans_default_options 后添加启动参数-J-Dfile.encoding=UTF-8(别忘了加空格)

二、文件内容乱码：

首先确定项目编码是否与文件编码一致，可在 项目属性对话框中的 编码里设置。

如果编码一致，一般就是字体原因引起，查看下 工具-选项-字体和颜色中所选字体，如果为英文字体，中文内容就会出现方块类似的乱码

可以尝试选择包含英文的中文字体（如微软雅黑）即可解决，如果又想使用英文字体显示英文，中文字体也能正常显示，需要

1.改变下jre的字体查找顺序

{jre 安装目录}/lib/fontconfig.properties (没有的话将fontconfig.properties.src 文件复制重名成fontconfig.properties)，打开后更改里面这一行：

sequence.monospaced.GBK=chinese-ms936,alphabetic,dingbats,symbol,chinese-ms936-extb

调整下字体查找顺序，先查找英文再查找中文，即：

sequence.monospaced.GBK=alphabetic,chinese-ms936,dingbats,symbol,chinese-ms936-extb

2. netbeans中工具-选项-字体和颜色 选择为继承的，即：Monospaced

重启下netbeans 应该就ok了。

当然也可以不更改jre配置，选择一种包含你想要的英文字体和中文字体的混合字体也行，比如：雅黑-Consolas，可惜我习惯了 courier new ~，尝试用 fontcreator 合并 雅黑和courier new 效果也不好，好像是因为字体 类型不同所致，不管了反正感觉不靠谱，有兴趣的可以自己合并试试。

上下配色截图,hh

1. IE dom方法赋值变量调用错误
2. IE 的<html>元素border问题

IE dom方法赋值变量调用错误

如下代码：

    var s = document.getElementById;
    alert(typeof s);
    var el = s.call(document, 'test');
    el.innerHTML = "ok";

应该alert出什么？el里的文字是？

按道理应该alert出 function，文字是ok，但在ie下却alert 出 object，IE7/8下文字是ok，ie6下却报错

“object doesn’s support this property or method”

test demo

因此应避免将dom方法直接付给变量，再来看看另一问题

IE 的<html>元素border问题

在计算元素offset时经常用到docuementElement.offsetHeight,documentElement.scrollTop

比如要实现一个元素固定居于浏览器右下角，ie6下通过脚本实现：

    var el = document.getElementById('test'),
        htmlEl = document.documentElement;
    function rb() {
        el.style.top = htmlEl.scrollTop + (window.innerHeight||htmlEl.offsetHeight) - 50+'px';
    }
    window.onscroll=rb;
    window.onresize=rb;

offsetHeight是指整个元素的高度(border box)，在ie下html元素错误的box模型，offsetHeight返回的也是窗的高度

test demo

看下测试demo发现ie无限向下滚动，原因在ie下html元素有2px的border，而元素定位是相对body的这样每次计算都多出2px

将offsetHeight改为clientHeight ok！clientheight是元素内容区域的高度（padding box）

以后处理基于<html>元素定位问题时需要留意这2px的box

最后看看jquery offset方法的实现也是对这个问题进行了处理，offset.js