开发页面在很多人眼里很简单，大部分的人都会说不就是把效果图变成网页嘛，哪里需要那么多的时间，一点技术含量都没有。确实html页面没有js那么多复杂的交互，也不需要和后台数据打交道，但并不能代表就没有技术含量，也不是人人都能做好的。页面结构好坏直接会影响到css代码的质量，也会影响js和后台的开发，还会影响到以后功能的扩展和代码的优化。

前端页面的工作很琐碎，需要的不仅是基础知识的扎实，知识面的广泛，很重要的一点还要细心。下面我们就讲讲页面开发，开发中需要事项和常遇到的问题吧。

首先分析效果图，细节上是否和站内风格统一；设计的元素是否便于实现；元素是否能复用。有问题及时和产品人员进行沟通，避免开发过程中的频繁修改，影响工期和代码的质量。这些都是为更好的布局和精简css代码做的必要工作。

合理布局很重要，如同大厦的地基，大厦的高度再于地基是否牢固，合理的布局能有更好的扩展性。结构要尽量简洁，尽量减少结构中的嵌套，不要为了实现某种样式添加多余的空标签。

标签尽量语义化，能够让代码更加清晰。现在html5添加了更多的语义化标签，像header，section等，大胆的使用吧。虽然html5对于标签的相互嵌套体现了很好的包容性，即使标签没有闭合，或是inline元素中包含一堆block元素也不会有问题，但是为了养成良好的习惯还是尽量做到严格遵循xhtml的规范。

尽量少在页面写inline css,会使页面代码臃肿，不便于维护，有悖于样式和结构相分离的初衷。

页面中推荐的两种注释：

<%!–jsp注释,不会输出,推荐使用–%>

另一个总和前端页面开发打交道的就是图片。图片分为两种，一种是cssimage引用，另一种纯Image的页面引用。

背景图是通过样式在页面上输出，会在页面中产生请求，延长页面的渲染时间，为了解决这个问题，可以把类似的图片进行合并，减少请求数。在进行合图的时候，尽量把颜色相近的图标放到一起，可以减少图片的大小。

页面中直接引用的图片尽可能少的缩放，非常影响页面的渲染速度；尽可能少的使用前端技术控制图像显示大小，对用户不可见的部分就是浪费带宽，浪费钱，页面的渲染速度也肯定会受到影响，影响用户体验；在知道图片宽高的情况下尽量在img中加上宽高，减少页面reflow造成的速度损耗。

静态图片一定要小，建议存成png8格式，在不影响图片的显示质量下，可以选择128色或是更低的颜色输出图片。当然有的色彩比较丰富的图片，存成jpg格式的更小，难道你会非选png的吗？存储完后图片还能用一些压缩工具进行无损压缩（如：PNGGauntlet）。

对于图片来说小就是原则，为什么呢，给你算个帐，节约10K看不出什么，100个用户是1000K，10000个是100000K,那一亿个用户呢？全是白花花的银子啊！

图片有几点需要注意：
1、我们在使用背景图做图标的时候通常会在页面加一个钩子——img标签，img标签中的src中一定要写上存在的图片链接，人人网通常使用的是一像素的图片代替（http://a.xnimg.cn/a.gif）。如果你忽略了这个地址，页面上会有一个404的请求，在ie6下直接显示一个叉。
2、如果你的工程已经上线，我们站内对静态文件会有一个缓存机制。在开发过程中，经常会遇到修改图片的情况，如果你修改后的图片不更改文件名或是在样式中更改引用该图片的版本号，对于用户而言，他们仍然看不到修改后的图片。所以，一定要记得修改文件名。
3、避免过小的背景图平铺。
4、尽量将图片上的文字提取出来用代码实现，便于图片的复用和日后文案的修改；

css主要说一下注意事项。
1、class命名建议以功能而不是外观命名，不建议使用大小，避免起容易冲突的名字，防止样式被覆盖。
2、CSS后代选择器性能：.a{} > .b .a{}，查找匹配耗费cpu,代码复杂，优先级高，修改不方便；
3、编码时尽可能使用缩写，如padding：top right bottom left;border-width:1px 0;border-color:#CEE1EE;color:#F05;
4、使用CSS display:none隐藏的元素不会被搜索网站检索，会影响到网站的SEO，可以使用text-indent:-9999em;来达到同样效果。
5、减少overflow清除浮动的使用，避免使用无意义的空标签清除浮动，通常站内使用clearfix来清除浮动。
6、border:none;替换border:0;的写法；
7、使用css3的属性来代替阴影或是圆角的图片；

浏览器的兼容问题是页面开发的永衡话题。结构的合理和简洁在很大程度上可以减少兼容性的bug,但是ie的特立独行又不可避免有一些兼容性问题。
IE6、IE7、Firefox之间的兼容写法：
写法一：
IE都能识别*;标准浏览器(如FF)不能识别*；
同一类class下的CSS hack可写为：
.classname{
background-color:#333;/*三者皆可*/
*background-color:#666; /*IE*/
_background-color:#999; /*仅IE6及IE6以下*/
}
一般三者的书写顺序为：FF、IE7、IE6.
写法二：
*+html 与 *html 是IE特有的标签, Firefox 暂不支持。
.classname{background-color:#333;}
*html .classname{background-color:#666;}/*仅IE6*/
*+html .classname{background-color:#555;}/*仅IE7*/
常见的css bug这里就不说了，稍后会在wiki里总结一个列表供大家查阅和参考。

对于样式和图片的引用a.xnimg.cn,s.xnimg.cn,xnimg.cn。这三种的区别是a.是在其他地方的域，s.是在北京本地的域，xnimg.cn是曾经的域，通常现在使用a.xnimg.cn,除非非常重要的静态文件才使用s.xnimg.cn。

在开发过程中，我们应该对bug出现有预见性，特别是常见的bug（QA经常提的bug比如连续字符串没有换行，鼠标在没有变成手型…）要提前做出处理。要考虑各种极端数据和不同大小图片在页面中的显示情况。对于代码进行合理的规划，减少冗余，可以简单写下注释，便于以后修改。

再来说一下快速查bug和解决bug的一些个人见解吧。
首先要分辨bug的类型，有的bug不一定是页面的问题。是否是页面套错了某个标签没有闭合，是否需要js修改或是后台技术处理。
查bug，工具是必不可少的，firebug,ie的IEDevToolBar,chrome自带调试工具都能进行调试和修改；使用工具能很快定位bug的位置和类型，作出修改。
经验的积累也是很重要的。有时候你使用了所有的方法解决但问题仍然存在，需要看看DOCTYPE是否在HTML顶部，是否完整，推荐；是否有多余的空格或是编码格式是否正确，
比如ie解析的空格间距不太一样，有时候会导致意想不到的bug。
还有一种方式是逐步删代码方式，看究竟是那个部分是有问题的。

解决bug常用的几个方法：
有人说zoom:1;是解决ie6的兼容问题的万精油。可以用，但是不易多用，这个属性可能会存在一些潜在的问题，至于是什么问题，大家可以google一下。
position:relative;往往和overflow:hidden;搭配使用能解决ie下滚动图片侧漏问题哦。

最后要说的是优化，一定要时时刻刻想着优化自己的代码，给用户带来最好的体验。永远记住这句话【HTML结构的简化>css代码结构的简化】

源文：http://fed.renren.com/archives/373

©2012 香樟树. All Rights Reserved.

接触Mobile WEB前端开发将近一年时间了，在这不算短的时间里，通过吸取圆心、沉鱼等前辈们的经验以及不断的摸索和实战，总结出一套自己的Mobile WEB“研发流程”。为什么叫“研发”流程而不是“开发”流程，在下文中会进行解释。首先我们来看一下“研发”的流程图：

各大 javascript 框架和类库都有一套独自的选择器，我花了点时间自己开发了一套选择器，在性能测试方面也不输给 jQuery 的 sizzle。在 javascript 选择器的开发过程中，学到了不少东西，这些东西如果自己不去开发，估计永远也没机会学到。现在，对于 javascript 选择器的原理以及如何去实现都有了一定的了解，在这里，我觉得有必要将一些心得记录下来，并分享给有需要的人。

jQuery 在 CSS3 的选择器出来以前，就实现了很多自己私有的选择器，虽然这些私有的选择器在日常的应用中使用率都不太高，但是其作为一个类库，要适应和兼容各种场景，面对各种技术水平的web开发者，这些私有选择器还是有不小的用处，甚至可以说，CSS3 的选择器在一定程度上也吸纳了 jQuery 的私有选择器的思想，在它的基础上再做一些改良，使之成为现在的 W3C 标准。

我的选择器将尽量遵循 CSS3 选择器的 W3C 标准，并适当的加入一些非标准但是比较有用的选择器，下面是支持的选择器列表：

/* 基本选择器 */
E
E#myid
E.class

/* 关系选择器 */
E > F
E + F
E ~ F

/* 属性选择器 */
E[attr]
E[attr="value"]
E[attr!="value"]    // 非标准
E[attr*="value"]
E[attr~="value"]
E[attr^="value"]
E[attr$="value"]
E[attr|="value"]

/* 伪类选择器 */
E:nth-child(n)
E:nth-last-child(n)
E:nth-of-type(n)
E:nth-last-of-type(n)
E:first-child
E:last-child
E:first-of-type
E:last-of-type
E:empty
E:not(s)
E:enabled
E:disabled
E:checked
E:selected    // 非标准
E:hidden    // 非标准
E:visible    // 非标准

熟悉 jQuery 的都知道 jQuery 有很多表单选择器，如:text、:password、:radio等，这些表单选择器完全可以用属性选择器来实现，如input[type="text"]，还有 :first、:last、:even、:odd、:eq 等伪类选择器，这些选择器也完全可以用 :nth-child、:first-child 等标准的伪类选择器来取代。给用户的选择越多，也会使用户更加迷惑。从用户的角度出发，符合标准既能减少学习成本又能实现常用的功能。

标准浏览器以及IE8都有一个 querySelectorAll 的方法，该方法支持符合 W3C 标准的选择器，其中IE8只支持到 CSS2，不支持 CSS3 选择器，所以自己开发出来的选择器的主要是应用于不支持 querySelectorAll 方法的浏览器(主要就是IE6和IE7)。

基本选择器

下面是一个比较常见的选择器：

#box .list p

该选择器由3个部分组成，#box : id选择器，.list : class选择器，p : tag选择器。这算是3种最基本的选择器了，一些复杂的选择器都是从这个基础上加以演变而来。接下来对这个选择器进行分割，可以用正则或者字符串的 split 方法转换成数组，那么上面的选择器字符串将变成下面的数组形式，有了这个数组，接下来就好办了。

[ '#box', '.list', 'p' ]

选择器的查找顺序有从右到左，也有从左到右，我的选择器使用的是从左到右的查找顺序。不管是从右到左还是从左到右，只要速度够快就行，如果你觉得从右到左更有意思，更能体现技术水平，你大可以去尝试下，如果你的选择器在性能上比我的更好，那么我就服你了。这么说的原因只是觉得要实现某个功能可能有好几种方法，不管是使用哪种方法，结果的优劣才是最好的说明，当然，这不是绝对的，使用哪种方法更好也是因人而异的。

有了数组，确定了顺序，现在可以一个个查找了。从第一个 #box 开始，这个我们一看就知道是 id 选择器，但是 javascript 不能看，只能查找特征来区分，#box 的特征符号就是“#” ，以此类推 .list 的特征符号就是“.”，那么 p 的特征符号是什么呢？tag选择器没有特征符号，如果排除了 id 和 class 选择器，剩下的不就是 tag 吗？

将第一个查找到的结果作为第二个选择器的上下文(context)，那么第二个选择器将在第一个选择器的上下文中查找结果，这样以此类推，直至查找到最后一个选择器，最后一个选择器的结果就是整个选择器的结果。可以用一个数组来存放查询结果，每次都读取最后一个数组元素来作为查找范围。第一个选择器如果没有指定查找范围，那么这个查找范围就默认为页面的根元素 document。最后为了便于操作，将最终的查找结果转换成真实的数组，因为查找结果可能会是 nodelist 的 array-like 的数据。

我的选择器的实现思路基本就是这样，通过上面的分析后，选择器的开发思路其实并不难，有了这个思路，其他类型的选择器同样可以效仿之。

关系选择器

关系选择器主要包含3种，当然也可以将空格的算进来，那么就是4种。

按照基本选择器的实现思路，那么关系选择器的特征符号就分别是“ ”、“>”、“+”、“~”。关系选择器就是先查找children、nextSibling元素，然后进行相应的过滤。比如 div + p，按照从左到右的顺序先查找 div 元素，然后查找 div 的 nextSibling 元素，最后再通过 p 的 tagName 来进行过滤得到结果。部分关系选择器使用从右到左的顺序可能会更快，以后做优化的时候我会尝试。

属性选择器

标准的属性选择器有7个，各框架和类库的选择器中都有一个私有的属性选择器“!=”，这个是非标准的，但是比较有用。

属性选择器的特征符号是“[”，需要注意区分的是“~=”和关系选择器的“~”。如 div[class="test"] 可以分割成4个部分：

• 1、tag 选择器 div
• 2、attr (属性名) class
• 3、过滤符号 =
• 4、value (属性值) test

先查找到 div 元素，然后使用 getAttribute 方法来获取该元素的属性值，最后通过各种过滤方法进行过滤。需要注意的是 getAttribute 方法不能滥用，部分属性是可以直接取的，如 elm.type ，不通过 getAttribute 方法性能会有所提升。

伪类选择器

伪类选择器易于扩展，所以大部分的jQuery的私有选择器都是伪类选择器。标准的伪类选择器主要有索引伪类(也称位置伪类)、表单伪类等。伪类选择器的特征符号“:”后面可以是任意的字符串，如果想自定义某种伪类选择器会非常方便。

如何分割伪类选择器？比如 p:nth-child(enev) 可以先分割成2个部分：

• 1、tag 选择器 p
• 2、伪类选择器 nth-child(enev)

用中划线“-”来判断是否为索引伪类还是其他的伪类，其他伪类的实现很简单就不多说，这里简单的说下索引伪类。得到了nth-child(enev)可以继续分割：

• 1、nth-child
• 2、even

到这一步还可以继续分割，也可以不分割，就看你要用什么方法来处理了。标准的索引伪类选择器都有一定的规律，找准规律才好处理。nth系列的伪类比较麻烦，因为其参数的种类很多：3、3n、3n+1、3n-1、even、odd，这些参数一看就蛋痛。还是拿 p:nth-child(enev) 来说，先查找 p 元素，然后查找 p 元素的父级元素，再通过父级元素得到 firstChild，再从 firstChild 入手，遍历 nextSibling 元素同时过滤索引，对于p:nth-last-child(enev)，就反过来查找，从 lastChild 入手，遍历 previousSibling 元素。

首尾索引伪类 first-child、last-child 等系列选择器，也同样可以查找 nextSibling、previousSibling 元素来进行过滤，如果是 firstChild 元素，那么其 previousSibling 元素必然为 undefined。

这些索引伪类的实现方法比较多，这只是我个人觉得速度还不至于太慢的方法，也都是简单的说说思路。

选择器的性能测试，我会在年后放出来，马上要过年了，在这里祝大家新年快乐！

http://pugetworks.com/2011/04/css-media-queries-for-targeting-different-mobile-devices/

http://blog.sina.com.cn/s/blog_83940dfb0100yrfm.html

http://developer.android.com/guide/webapps/targeting.html

http://www.fiveminutes.eu/targeting-hight-screen-densities-with-css-media-queries/ 

   1）做一套比较简单的UI，在美术和排版设计上，保证图片可以自由伸展 —— css中的滑动门设计，大家懂的吧？设计就做个类似滑动门的设计，保证两头不变，中间可以自由拉伸。技术上别在最外层设一个固定宽度了，流体布局，你懂的。这种做法实现成本最低，但相应的，在美术设计上也会有很大的限制，不能对不同的分辨率做相应的最好设计，一般来说，美术设计都会相对很简单。

   2）针对不同的分辨率，做几套不同的美术排版设计，然后在技术上写几套不同的代码，嗅探一下设备的分辨率，不同分辨率用不同的代码。这么做的好处是不同的分辨率下都能有最适合的美术排版设计，但相应的，开发和维护的成本都会大增，而且非常令人头痛的是pc、android、ios、winphone等不同设备的分辨率不同，舍弃哪些，选择哪些，如何向未来兼容等等都是头痛的问题。

   一般来说，用第一种解决方案是比较常见的做法，毕竟实现成本低，可维护性高。但用第一种方案的话，有个前提条件是“界面允许向下滚屏”，因为内容是固定的，但宽度是不确定的，所以高度也是不确定的。如果设备宽度够宽的话，那么高度自然就小，比如一段文本在320px宽度下占10行，在640宽度下可能就只占5行了。“界面允许向下滚屏”是采用这种方案的一个必要条件。

  但有些应用，对滚屏就非常敏感了，它们希望只用一屏来显示内容。这时，第一种方案就无法使用了。我们当然可以选择第二种方案，但其实还有另一种方案——使用viewport，设置一个固定宽度，在浏览器里开发的时候，只用针对这个固定宽度来开发，通过dpi的缩放来适应各种设备的真实分辨率。关于viewport在ios和android下的具体设置可以参考我上一篇博客：http://hi.baidu.com/cly84920/blog/item/b3c292a778a30e8bd04358f2.html 。

  但其实通过设置viewport也会遇到头痛的问题 —— 在android下，设置缩放是通过手动指定dpi来实现的，并不是直接设置缩放后的width(这点和ios不同)，这就遇到一个麻烦了，dpi和具体的物理尺寸是直接相关的，3.5寸、4.0寸、7寸、9寸甚至平板电视40~60多寸，要想通过dpi，在浏览器里保持同一个width的话，就必须得知各个设备的真实分辨率和其物理尺寸，动态地计算出dpi的值，通过js去设置viewport，可是，物理尺寸在js中拿不到啊! 好的解决办法没有了，只能针对主流设置进行取舍了，不可能照顾到所有设备了。在面向未来的兼容上，是个头疼的问题。

  在“不滚屏”这个制约条件下，我共能想到三种实现方法，列了一下优缺点：

1）设置viewport的宽度为800（目前android主流的分辨率为480 * 800），高度取所有主流设备的最低高度。

【优点】：

<1> 图片只设计一套、美术排版一套、程序只开发和维护一套

<2> 向前兼容更好（不用时刻关心最新的市场行情——新的主流分辨率）

<3> 兼容新的设备更容易（不用去调查新设备的分辨率在市场上的分布，只针对viewport的800宽编程）

【缺点】：

<1> 有dpi缩放，质量会失真

<2> 兼容android设备时，无法得知物理尺寸，无法很好兼容所有尺寸的设备

2）设置width为device width，但主体区域仍然按800像素宽进行设计和编码，主体区域居中，其余地方用背景图铺满，也就是一个假满屏。

【优点】：

<1> 无dpi缩放

<2> 图片只设计一套、美术排版一套（背景图要求比较大），程序开发和维护一套

<3> 兼容新的设备容易

【缺点】：

<1> 在大分辨率小，主体区域会显得非常小，影响可用性

<2> 向前兼容不好

3）设置width为device width，真正按deveice width去设计主体区域，也就是一个真满屏。

【优点】：

<1> 无dpi绽放

<2> 对各个平台用户界面设计保持最佳。

【缺点】：

<1> 图片出多套

<2> 排版设计复杂度高，考虑各种分辨率情况

<3> 向前兼容性不好，需时间关注市场最新动向，对新的主流分辨率进行支持

<4> 兼容其它终端麻烦，需再做调查，再开发新版本

<5> 代码需编写和维护多套，且不断更新，嗅探器多

　　1. The Heads-Up Grid

　　使用HTML，CSS和Javascript开发。head-up Grid是一个符合responsive的overlay grid，专门为浏览器网站开发设计。用来相对简单的来满足对于responsive web设计的需要。

　　2. FitVids.JS

　　一个轻量价的，为video嵌入自适应宽度而开发的jQuery插件。为了实现responsive web设计中的流动宽度效果。

　　3. AdaptiveMedia

　　使用adaptivemedia，你只需要一个CSS文件来定义所有的窗口大小，不需要更少或者一样的解决方式，不需要CSS3 media queries，小于3kb，HTML5和IE6兼容。用户callback：在完成所有任务之前完成用户方法。

　　4. rlightbox

　　一个jQuery UI的mediabox，可以用来显示各种类型的内容，例如，图片，youtube和vimeo视频。拥有很多独特的特性例如， 全景图和实时改变大小，和其它的jQuery UI一样，支持ThemeRoller。

　　5. Elastislide

　　一个responsive jQuery的轮播器，在不同的屏幕大小上会自适应尺寸

　　6. Responsive Image Gallery with Thumbnail Carousel

　　使用Elastislide这个插件，这个技巧将展示如何执行一个responsive的web设计图片画廊，能够根据可视区域来改变大小。拥有一个切换器来切换缩略图轮播。支持键盘d导航

　　7. Seamless Responsive Photo Grid

　　用来管理照片的比例

　　8. Responsive jQuery Slideshow

　　这个演示展示了如何实现缩放的自适应。和kiskolabs.com使用一样的实现方式

　　9. wmuSlider

　　记住还处于实验状态，使用MIT license。

　　10. Doubletake

　　用来试验一个概念，Doubletake是一个根据浏览器宽度动态更新图片src属性的插件。开始时是一个手机上可以浏览的小图片。然后doubletake会使用一系列定义断点来根据需要更新src

　　via jquery4u

本文链接：http://www.yixieshi.com/web/10137.html

postMessage 方法 JSONP 技术不一样，前者是前端擅长跨域文档数据即时通讯，后者擅长针对跨域服务端数据通讯，postMessage 应用场景能说明这个区别：

应用场景举例

1. webOs 使用 iframe 嵌入第三方应用，此时 webOs 与应用需要实时接收/发送各自的消息与相应事件。
2. 页面弹出一个由 iframe 层，嵌入第三方提供的图片上传页面，文件上传完毕后需要获取返回图片地址插入到编辑器。
3. iframe 跨域高度自适应。

HTML5 postMessage 方法

postMessage 可以实现跨域文档的消息传输（Cross Document Messaging）。

向外界窗口发送消息：

otherWindow.postMessage(message, targetOrigin);

otherWindow: 指目标窗口，是 window.frames 属性的成员或者由 window.open 方法创建的窗口

参数说明：

• message: 是要发送的消息，类型为 String、Object (IE8、9 不支持)
• targetOrigin: 是限定消息接收范围，不限制请使用 ‘*’

HTML5 message 事件

绑定消息事件：

window.addEventListener('message', receiver, false);
function receiver (event) {
  if (event.origin === 'http://example.com') {
    if (event.data === 'Hello world') {
      event.source.postMessage('Hello', event.origin);
    } else {
      alert(event.data);
    };
  };
};

回调函数第一个参数接收 Event 对象，有三个常用属性：

• data: 消息
• origin: 消息来源地址
• source: 源 DOMWindow 对象

“messageEvent.js”是一个开源库，它模拟了 message 事件与 postMessage 方法实现跨浏览器兼容。

messageEvent.js 跨域通信实现原理

对于支持 postMessage 方法的浏览器直接使用它；而对于 IE6、7 采用了比较成熟的 window.name 保存数据以及跨域 iframe 静态代理动态传输方案，下面简称 Cross Frame。

假设在域 www.a.com 上有页面 a.html 和代理页面 proxy-a.html ， 另一个域 www.b.com 上有个页面 b.html 和代理页面 proxy-b.html，a.html 需要向 b.html 中发送消息时，页面会创建一个隐藏的 iframe 指向 proxy-b.html ，并把消息赋予 iframe.name 属性，此时 proxy-b.html 可以通过 window.name 获取到消息，由于 proxy-b.html 与 b.html 是同域，proxy-b.html 可以把消息赋予 b.html。 b.html 要给 a.html 发送消息时，原理一样。

自动捕获代理 URL

在 Cross Frame 方案中，通信双方必须确切的知道静态代理文件的 URL，显然这个极大的限制了应用范围，我们可以通过一些约定改善：静态代理文件必须置于通信页面所在域根目录，且文件名必须保持一致，如 messageEvent-proxy.html。

有了上述约定，接下来可以用一些巧妙的方法让双方自动捕获代理 URL。接下来以 http://www.a.com/a.html 通过 iframe 嵌入 http://www.b.com/b.html 保持数据交换为例进行说明：

b.html 的静态代理路径可以通过正则分析 iframe.src 后得知；而从框架 b.html 内获取父页面就比较麻烦了，因为跨域后的 parent.location.href 属性只可写入不可读取，不过还可以借用 document.referrer 属性来分析来路地址得知父页面 url。document.referrer 是一个不稳定的属性，我们可以利用 iframe 中 window.name 刷新也不会变化的特性，用此来保存父页面 a.html 的地址。

持续跟踪 URL

a.html 第一次通过提取 iframe.src 路径可得知 b.html 的地址，假若 b.html 跳转到其他域名的时候，此时就会失去对 iframe 内静态代理的联络。 好在新页面由于能够获取父页面 a.html 保存在 window.name 的静态代理，所以我们仍然可以在新页面初始化的时候向 a.html 传递消息告诉它新的地址。

messageEvent.js 的接口

到目前为止， messageEvent.js 已经在低版本浏览器模拟了原生方法、事件、属性，它能传递多达 2MB 的文本信息，并且能让 IE6-9 浏览器像其他现代浏览一样支持深拷贝 Object 类型数据进行传递。

• add(callback) 添加 message 事件
• remove(callback) 卸载 message 事件
• messageEvent.postMessage(otherWindow, message, targetOrigin) 向外部窗口发送消息

通过 jQuery 使用 messageEvent.js

jQuery 是一个应用比较广泛的 DOM 库，它的事件机制非常强大而精妙。若页面引用了 jQuery， messageEvent.js 会为为它提供支持，你可以用熟悉的jQuery api 风格编程，如：

jQuery(window).bind('message', function (event) {
      alert(event.data)
});

jQuery(window).message(function (event) {
      alert(event.data)
});

jQuery.postMessage(iframe.contentWindow, 'hello world', '*');

由于 jQuery 把包装后的 Event 对象用 data 属性来保存 bind 方法传入的额外数据，导致与 message 事件自身的 event.data 属性冲突，这是一个设计错误。为了让 message 事件能够正确获取 event.data，messageEvent.js 通过操作 jQuery 底层缓存强制覆盖了 bind 方法传入的附加数据 (只针对 message 类型)。当然，我仍然期待 jQuery 未来版本能够取消掉 bind 方法的鸡肋特性。

项目地址

项目主页： http://code.google.com/p/message-event/
在线阅读最新版源码： messageEvent.js | messageEvent-proxy.html

项目下载包提供了文档与示例，若有疑问或者建议欢迎评论或者在腾讯微博上交流，望共同改进： http://t.qq.com/k/messageEvent.js

唐斌 – 2012.01.05 – 深圳