HTML教程:iframe标记常见的几种使用方法

iframe标签在网页中可以创建一个内嵌框架，通过指定src属性来调用另一个网页文档的内容。和frameset一样，用它来对网页结构进行拆分以使网页的某些部分保持公用，但相对frameset对整个网页进行框架结构的拆分来说，iframe更加灵活，可以内嵌到网页的任意地方。由于iframe使用上的这个特点，在一些网页中得到了大量运用，也导致了一些不适宜的滥用。网页设计将分析一下iframe这个网页元素常见的几种使用方式。

1. 制作“无刷新”响应页面组件，作为异步交换数据的一种解决方案。这是早期不使用ajax来异步发送请求的一种替代方法，通过在页面上设置不可见的iframe元素，并将其src属性指向需要发送请求的页面地址来发送请求，同域下可以再对返回的页面进行dom解析来获取数据。另外一个好处在于绕开了ajax的沙箱安全模型，可以顺利发送跨域请求获得数据，只是这种情况下取不到iframe的document对象。因为它的这个特点，在某些需要跨域请求数据的网页中依然有应用。这种无刷新是指在数据交换过程中父页面不刷新而继续对用户操作保持响应，实际进行数据交换而被锁定的是父页面上内嵌的iframe页面。这个内嵌iframe页面根据需要设置为可见或不可见都可以，并不会影响父页面中的其他元素对用户的响应。这种效果类似ajax的无刷新，但可以看出其机制是完全不同的。即使gmail作为ajax应用的典范，也结合了很多iframe来实现其优越的性能与用户体验。
2. 优化页面的一种方式。使用iframe可以并行加载脚本，解决加载缓慢的第三方内容如图标和广告等的加载问题。google的广告平台adsense即通过iframe在用户的站点上投放广告分享收益，查看分析国内门户首页上的广告代码也能看到这类技术。也可用隐藏的iframe在网络压力较小的时候来预加载比较大的文件到缓存，以便其他页面使用。预加载的概念可以用firebug分析google首页，在body标签里可以看到：
   

   onload=”document.f.q.focus();if(document.images)new image().src=’/images/nav_logo4.png’”

   这样一句代码，加载的图片nav_logo4.png在首页并没有用到，但搜索结果列表等其他页面使用此图片的时候只需要从缓存读取，不需要重新下载了。

3. 作为针对ie6浏览器中浮动层遮不住select控件和flash元素的一种修正(hack)方式。web2.0时代lightbox（又或thickbox）技术以它良好的体验与清新的视觉感受成为一种流行效果。这种技术实际上是用一个绝对定位的浮动层覆盖到原有页面上，用以呈现文本信息、图片、表单或其他任意页面元素，替代了早期web开发中常使用弹出浏览器窗口或者浏览器自身的消息、输入控件来与用户进行交互的方式。旧有方式中，弹出新窗口的脚本经常会被浏览器的广告拦截系统拦截，而浏览器自身的消息控件因为会打断浏览器进程，导致浏览器中本页面以及其他通过多标签进行浏览的网页全部被锁死而受到用户体验研究者的诟病。作为对自己有严格要求的一线web前端开发人员，在动手实现lightbox效果的过程中一定会遇到这个问题，绝对定位的层在ie6中遮盖不了网页上的select控件和flash，即使样式设置较高的z-index值也无济于事。这是因为select元素在ie6中是一个窗体级别的元素，它的优先级大大高于其他所有的html标签，只有同样窗体级别的iframe才能遮住它。因此开发者们研究出，把浮动层放到iframe中，或者在浮动层中放置一个iframe就可以解决此问题了。所幸此问题在ie6以后的ie升级版本中得到了修正，但对于还拥有50%+市场占有率的ie6来说（统计截至发文时间），这个解决方案依然有现实意义。

除了以上三种应用，对于iframe元素也常见一些不恰当的运用。例如在页面中嵌入过多的iframe框架，通过指定框架外链接标签的target属性在点击时来更新iframe，这种用法和frameset类似，达到共用导航的目的。初衷是好，但其中的弊病也毋庸置疑。这样会导致一个页面请求过多，上文所提及的雅虎团队《best practices for speeding up your web site》一文中就明确优化页面需要“使iframe的数量最小”，归纳了其三种弊病：

1. 即使内容为空也会造成资源损耗(包括客户端、服务器端)；
2. 阻滞页面onload事件触发（“blocks page onload”，又有译作“会阻止页面加载”，此处存疑）
3. 没有语义（seo是网站营销的重要组成部分）

在xhtml1.0的下一个版本html5中，由于frameset标签对网页可用性方面产生的负面影响，没有对它提供支持，这也从侧面说明一些问题。

另外，由于内嵌的iframe不能自动适应其内部内容大小，为了保持页面显示的完整性，还需要编写一段javascript脚本来根据iframe内容的变化即时调整其大小。分散的多个请求再加上需要javascript脚本来修正更增加了多iframe页面系统运行的风险。那么，有没有什么好的方法能保持部分页面内容公用呢？服务器端早就给我们提供了解决方案，asp中的include，php中的require方法，都是用来包含一段已有的代码到程序中，这样同样能实现页面的某个部分（如导航菜单、页脚）公用，但是运行之后作为一个完整的页面输出，有效地减少了客户端请求，同时也不存在iframe的高度自适应的问题。