准备阶段最重要是关于HTML/CSS和Javascript如何协作的问题。

浏览器初始化顺序是首先脚步，然后是statements，最后是html。

如果在js里面直接引用body里面的element就会报错，最好是把执行脚本放到函数里调用。

一些常见的钩子

id：创建钩子最简单的方法，每个id在文档中只能使用一次。
var x = document.getElementById('hook');

class：可以为一系列的元素初始化相同的行为。

自定义属性：即不属于(X)HTML规范的属性，这是不合法的，但有时为了脚本的方便使用它。

名/值对：即写成如下的形式，然后从className中通过操作字符串获取状态。

准备页面：设置事件处理程序，确定访问者状态，设置访问，产生内容，定义关系(relatedElement)，修改文档结构。

<script>标签

defer属性：表示正在加载中的脚本不包含任何会改变HTML的指令（如document.write）。Explorer仅在页面已经完全加载之后才会执行拥有defer属性的脚本。

XHTML规定包含内容的script标签必须定义成CDATA，它会告诉XML/HTML解释器不要解析这些内容，而是直接送给脚本引擎。

所有的脚本都被注册到HTML的全局对象中，同一个变量可以在多个脚本中使用，且为最后定义的那个。

当浏览器遇到script标签时，发送一个HTTP请求去获取脚本文件，解析其中的脚本，对HTML页面的分析和渲染暂停，直到脚本加载完成。

load事件会在页面完全加载时触发，window.onload = ; 多次设置onload会覆盖之前的设置，需要编写函数在同一个元素上设置多个事件处理程序。

等待load时会因为图片等造成延迟，这个问题很难解决，目前只有Mozilla支持的DOMContentLoaded事件，在文档加载完成后执行，不必等待图片。

每种浏览器都包含一个代码引擎或渲染引擎，它负责解释Web页面上的代码，javascript解释器是其中的一部分。

Netscape4惨败之后，网景公司于1998年创立了Mozilla项目，开发了Gecko引擎，现在它支持着Mozilla, Firefox, Netscape, Camino等浏览器。

Explorer的代码引擎叫做Trident，1999年3月发布的Explorer5.0是第一个支持W3C DOM和XMLHttpRequest的浏览器，但也是最后一个包含了主要Javascript更新的Explorer版本。

Safari于2003年发布，它使用KHTML代码引擎，它是Macintosh平台的默认浏览器。

Opera是一个独立的浏览器，在浏览器大战期间，它没有实现DHTML，现在看来，这是一个相当英明的决定。

4种兼容性问题

不支持：这些出现问题的功能不是“不可或缺”的基础功能，都能够通过对象检测判断，而且浏览器也在努力消除这些问题，如document.sytleSheets来读写整个样式表，目前Safari和Opera也增加了对其的支持。

合理的不同看法：如defer属性对加载脚本的要求，Exploer有独特的理解，幸好这种问题是最少有的。

有意为之的兼容性问题：通常是浏览器大战的遗留问题，也可以通过对象检测来判断，一旦微软着手实现W3C事件标准，最后一批被故意造成的兼容性问题也将得到解决。

浏览器bug：这是由于编程的缺陷造成的不可预见的错误，它是无法解决也是无法衡量的。如Exploer6会被normalize()方法导致崩溃。

浏览器兼容性问题是单纯的生活的事实，它不会轻易消失，应该尽快地习惯它，至少听任它。

在任何情况下都不要先为某一个浏览器写脚本，然后增加其他浏览器的支持。在项目支出就应该解决这些兼容性问题，而不是放在最后。

对象检测

对象检测是避免兼容性问题的最佳助手。它的一般方法是检查想使用的对象，看它们是否存在，如果不存在，就结束函数。（if(!对象)），从技术上说，对象检测是把一个对象转换成一个布尔值。

检查W3C DOM：

对W3C DOM的检测使我们可以总是假设浏览器也支持相关的功能，如appendChild，而省去对它的检查。

事件处理测试：

我们期望未来的版本使用标准，所以对标准的支持应该最先检查，事实上先检查attachEvent，Fx等浏览器会报错。

浏览器检测

为什么浏览器检测行不通？浏览器兼容性模式是不断变化的，今天不支持的属性，明天可能会支持；而且浏览器常常会伪装自己的身份，以便通过浏览器检测。

浏览器检测的军备竞赛

navigator.userAgent中保存了每一个浏览器的识别字符串。1995年前后的Mosaic和Netscape年代中，由于 Netscape的cookie和<center>标签等的支持，服务器端的程序员决定使用浏览器检测来区分两种浏览器，他们检测识别字符串 是否从Mozilla/开始，这给javascript世界带来了不必要的磨难。浏览器厂商被迫将自己的识别字符串变成从Mozilla/开始，即便是 Explorer最初进入市场时也将自己伪装成了Netscape。浏览器大战开始后，Web开发者们做出反应，他们创建了更多的浏览器程序来区分 Netscape和Exploer，而当战争结束时，已经有数不清的网站设置了检测脚本只允许Explorer访问，历史重演了，一些浏览器如 Opera，又不得不修改自己的识别字符串来匹配Explorer，甚至将识别字符串的设置开放给用户。

拆解浏览器字符串

第一个是Mozilla1.7.12，第二个是NT5.1(即XP)的Explorer6.0，第三个是Safari1.3.2，第四个是伪装后的Safari1.3.2。

userAgent：使用navigator.userAgent，而不是navigator.appName和navigator.appVersion。前者尚有一些遵循，后者都是谎言；

Mozilla/：只能证明浏览器是1994年后发布的；

/[version number]：没有意义，每一个现代浏览器都生命是第4版或第5版的Mozilla；

不规则字符串：通常被圆括号包围，包含这非常复杂的缩写；

Opera：唯一支持window.opera属性，可以检测这个对象来判断；

Safari, iCab和Konqueror：不像Opera那样勇于承担风险，它们可以完全地伪装自己；

Gecko：Mozilla识别串通常都会包含Gecko，但不幸Safari等也包含；

MSIE：没有意义，绝大多数的浏览器都包含MSIE；

版本号：Exploer和Opera允许在名字后面找到自己的版本号，而其他浏览器都无效，比如Mozilla的隐藏版本；

操作系统：Windows操作系统都以Win开始，当然这不适用于伪装的串。

(http://www.quirksmode.org/js/detect.html)

浏览器检测的正确使用

当你需要知道访问者的浏览器，如站点统计时，这些检测不会影响脚本逻辑。

当我们用对象检测时需要排除浏览器bug等时，可以将对象检测和浏览器检测一起使用。

调试

Mozilla有最好的错误信息，因此多在Mozilla中调试；

使用return，alert，confirm是不错的方法，复杂的调试可以自己创建一个错误控制台；

将bug报告给浏览器厂商。

javascript的目标是给Web页面增加一个额外的可用性层。

js分为6个部分：javascript核心、BOM(浏览器对象模型)、事件、DOM(文档对象模型)、CSS修改、数据检索(XMLHttpRequest)。

他们的任务：核心使得js成为一门编程语言的基础，控制结构变量函数和对 象；BOM给浏览器窗口下达指令，读取cookie，与其他窗口进行通信；事件找出用户执行的动作，并定义这些动作将触发的函数；DOM学习和改变 HTML文档的结构；CSS学习和改变HTML文档的CSS表现；数据检索从服务器下载新的数据而不刷新页面。

所有的脚本都是用核心语言、事件和DOM：等待行动，并更新页面。

ECMA(欧洲计算机制造联合协会)对javascript核心进行标准化(ECMA1.5)，这个标准应用到flash、浏览器、服务器以及其他尚未产生的应用上。

W3C(万维网协会)创建了DOM规范，它也包括事件处理和CSS修改的内容。微软仍然没有实现W3C的事件规范，却使用它自己专有的事件模型。

WHAT-WG(Web超文本应用技术工作组)正为BOM标准而工作。

数据检索使用的则是微软的事实标准，W3C为数据检索推出了XMLHttpRequest规范的第一部草案。

<script标签中允许在language="javascript1.2"中指定版本号，但自1.2版本开始Netscape和Explorer 4都宣称支持，因此设置版本号没有意义，事实上根本不需要这个属性。

js遵循严格的安全规范

不允许访问宿主计算机：不能读写除cookie外的文件系统

同源策略：两个窗口的页面的Web域名必须相同，才允许跨窗口通信。同子域下可以通过设置相同的document.domain(必须设置为真实域名的一部分)进行通信。

其他限制：不能读取历史对象的属性(当可以在历史中后退)；不能设置文件上传表单域的值；试图关闭窗口时会询问用户；不允许打开一个小于100x100或处于屏幕之外或没有标题栏的新窗口。

javascript的历史

创始人Brendan Eich当时在Netscape工作，js公开的历史从1996.3的Netscape2发布开始。

Eich最初的目标是为Web开发者提供一种简单的方式为页面增加一些交互，这些 脚本从其他页面复制过来并稍作调整就可以使用。最初命名为LiveScript。但Netscape出于市场的考虑选取了一个与当时流行的Java相似的 一个名字，并仓促地要求Eich“使这个语言看起来想Java”，从而误导人们将js视为轻量级的Java版本，看成一个可以拿来搬弄技巧而不值得引起严 谨的程序员注意的轻巧的脚本语言。

第一瘦时期

早期的日子里，浏览器是一个瘦客户端，表单验证和鼠标滑过的效果是令人惊艳的，但它们不允许在客户端大量进行交互，用户被迫与服务端交互。

1996~1999间Netscape与微软的浏览器大战开始，双方都推出自己的 第4版，为争夺CSS规范各不相让。两个浏览器厂商都让javascript可以控制这些CSS声明，于是就可以使用position:absolute 创建一个“层”，然后通过持续地改变top和left似的它在屏幕上移动，这才叫酷！这些小伎俩被冠以DHTML为人所知，即通过javascript来 改变css属性。

为此双方都推出了自己专有的DOM（又称过渡DOM，介于Netscap3DOM和W3CDOM之间），Netscape4支持document.layers，而Explorer支持document.all。

第一个胖阶段

有了这些新特性，客户端增加大量的互动：动画、隐藏和其他视觉效果，javascript的目标转向技术，而不是可用性，js进入胖阶段。

微软在1999年发布Explorer5，相当好地支持了CSS和新的W3CDOM标准。尽管公司和Web开发者尽力挽救，Netscape4还是灭亡了，差不多同一时间，js的第一个胖阶段结束，人们发现的不过是少量的javascript和大量的空话。

CSS变革开始。

第二个瘦阶段

浏览器大战接近尾声的时候，Web开发者们厌倦了大量的编程和变通做法，极度地想从头开始。CSS，而不是javascript，给了他们最好的机会来完全突破过去的束缚。

大概从2003年开始，一部分先锋开始用一种深受CSS革命理念影响的新方式写javascript，javascript第一次深深地潜入到全面的Web开发理论中去，而可访问性问题终于被认识到并着手解决。

无侵入脚本编程提出，但并没有立即征服世界。

第二个胖阶段

从服务器端悄悄地载入小块的数据，唤醒了沉睡多年的技术构思和可用性观 念，Jesse James Garrett的文章《Ajax：Web应用程序的新方法》开创了Ajax时代，javascript的用途又一次被重新定义，传统web开发者创建的是 瘦的可访问的乱糟糟的js代码，而来自服务端开发的“资深程序员们”创建的是面向对象的，胖的，可访问性差的ajax客户端。焦点又被集中在技术方面，可 用性及为什么要用ajax仍很少被关注，臃肿的库(即框架）与日俱增。

所幸人们都开始同意并遵循已经存在的标准。

2006.5数据显示，目前共有至少134中Ajax框架，我个人认为这股热潮已经到达了顶峰，有谁需要134种程序去做本质上是一样的事呢？

javascript将调整回瘦阶段，那时它的用途也将再次被重新定义，当然某个时期第三个瘦阶段结束后会迎来第三个胖阶段.. 从根本上，这种情况只有当每个人都只认同唯一的javascript用途时才会被打破。

1.     List<String> list = new ArrayList<String>();  
2.     for (int i = 0; i < 10; i++) {  
3.         String str = "td" + i;  
4.         list.add(str);  
5.     }  
6.   
7.     for (Iterator it = list.iterator(); it.hasNext();) {  
8.         String str = (String) it.next();  
9.         if (str.equals("td5")) {  
10.             // list.remove(str);  // 删除方法一 
    
11.             it.remove();  // 删除方法二 
    
12.         }  
13.     }  
14. } 
    

1. public boolean remove(Object o) {  
2.     if (o == null) {  
3.         for (int index = 0; index < size; index++)  
4.             if (elementData[index] == null) {  
5.                 fastRemove(index);  
6.                 return true;  
7.             }  
8.     } else {  
9.         for (int index = 0; index < size; index++)  
10.             if (o.equals(elementData[index])) {  
11.                 fastRemove(index);  
12.                 return true;  
13.             }  
14.     }  
15.     return false;  
16. }  
17.   
18. private void fastRemove(int index) {  
19.     modCount++; // 特别注意这里，这里只增加了modCount的值  
20.     int numMoved = size - index - 1;  
21.     if (numMoved > 0)  
22.         System.arraycopy(elementData, index + 1, elementData, index,  
23.                 numMoved);  
24.     elementData[--size] = null; // Let gc do its work  
25. } 
    

1. public E next() {  
2.     checkForComodification();  
3.     try {  
4.         E next = get(cursor);  
5.         lastRet = cursor++;  
6.         return next;  
7.     } catch (IndexOutOfBoundsException e) {  
8.         checkForComodification();  
9.         throw new NoSuchElementException();  
10.     }  
11. }  
12.   
13. final void checkForComodification() {  //注意这个方法
    
14.     if (modCount != expectedModCount)  //检查这两个值是否相同
15.         throw new ConcurrentModificationException();  
16. } 
    

1. public void remove() {  
2.     if (lastRet == -1)  
3.         throw new IllegalStateException();  
4.     checkForComodification();  
5.     try {  
6.         AbstractList.this.remove(lastRet);  
7.         if (lastRet < cursor)  
8.             cursor--;  
9.         lastRet = -1;  
10.         expectedModCount = modCount; // 设置expectedModCount  
11.     } catch (IndexOutOfBoundsException e) {  
12.         throw new ConcurrentModificationException();  
13.     }  
14. }  
15.   
16. final void checkForComodification() {  
17.     if (modCount != expectedModCount)  
18.         throw new ConcurrentModificationException();  
19. }