通常我们用 js 脚本创建 iframe 时，会这样写：

var iframe = document.createElement('iframe');

之后我们可能会定义 id、name、border 等属性，这些看似简单，其实 IE 与非 IE 浏览器之间、IE 和 IE 高版本之间的迥异，使得 iframe 的相关兼容性操作非常地有文章。

牛A：frameborder

现象：使用 (iframe.frameBorder = 数值) 或(iframe.setAttribute(‘frameborder’,数值)) 在 IE 浏览器下无效
原因：IE 浏览器区分属性名称大小写
解决方法：iframe.setAttribute(‘frameBorder’,'0′) Or iframe.setAttribute(‘frameborder’,'0′,0)，兼容所有浏览器。

注：经测试，IE8已经修复此问题

牛B：动态将Form target到iframe

背景：假设现在我们要让一个 Form 表单结果提交到一个 HTML 结构中已存在的 iframe，会这样做：

<form id="form" name="form" target="相应iframe的name:iframeNB" method="post" >
</form>
<iframe name="iframeNB" ></iframe>

OK，什么问题也没有，再假设我们需要提交到脚本动态生成的 iframe 中，会这样做：

<form id="form" name="form" target="iframeNB" method="post" >
</form>
<script>
var iframe = document.createElement('iframe');
iframe.name = 'iframeNB';
...
someParent.appendChild(iframe);
</script>

去 IE 浏览器里试试，你会发现 Form 会在新窗口显示提交结果，Why?
原因：
我为此尝试了很久，结果是IE此前版本不能通过(iframe.name=)这种方式给 iframe 设置 name 值，也就是说生成的 iframe 是没有 name 值的，但却可以 alert 出来，这很诡异；当然，这也并不是没有解决办法。
解决方法，为此我们得为 IE 单独写一行代码：

  /*only for ie */ 
    var iframe = document.createElement('<iframe name="iframeNB">'); 

看到这行代码，我们笑了，这是天大的杯具（喜剧？）～～不管IE有多么搓的问题，他总会有自己一套解决之……
而且这行代码会在其他非 IE 浏览器抛出异常，所以我们可以利用这点来做最终版：

    var iframe; 
    try{ 
        iframe = document.createElement('<iframe name="iframeNB">'); 
    }catch(e){ 
        iframe = document.createElement('iframe'); 
    } 
    iframe.name = 'iframeNB'; 
    ... 
    someParent.appendChild(iframe); 
    ... 

[2009-12-9]补充：最佳实践 – YUI 是如何 creat iframe 的

    /** 
    * @description Creates an iframe to be used for form file uploads.  It is remove from the 
    * document upon completion of the upload transaction. 
    * @method createFrame 
    * @private 
    * @static 
    * @param {string} optional qualified path of iframe resource for SSL in IE. 
    * @return {void} 
    */ 
    function _createFrame(secureUri){ 
    // IE does not allow the setting of id and name attributes as object 
    // properties via createElement().  A different iframe creation 
    // pattern is required for IE. 
    var frameId = 'yuiIO' + this._transaction_id,io; 
    if(YAHOO.env.ua.ie){ 
        io = document.createElement('<iframe id="' + frameId + '"name="' + frameId + '" />'); 
        // IE will throw a security exception in an SSL environment if the 
        // iframe source is undefined. 
        if(typeof secureUri == 'boolean'){ 
            io.src = 'javascript:false'; 
        } 
    }else{ 
        io = document.createElement('iframe'); 
        io.id = frameId; 
        io.name = frameId; 
    } 
    io.style.position = 'absolute'; 
    io.style.top = '-1000px'; 
    io.style.left = '-1000px'; 
    document.body.appendChild(io); 
    YAHOO.log('File upload iframe created. Id is:' + frameId, 'info', 'Connection'); 
    } 

这里需要额外注意到的一点是：

// IE will throw a security exception in an SSL environment if the
// iframe source is undefined.
if(typeof secureUri == 'boolean'){
io.src = 'javascript:false';
}

姑且算是牛D吧 =.=!

牛C：iframe.onload

关于 onload 这点大家可以参考怿飞师父的文章：判断 iframe 是否加载完成的完美方法，在此纯引用一次代码：

var iframe = document.createElement("iframe"); 
iframe.src = "http://www.planabc.net"; 
if (iframe.attachEvent) { 
    iframe.attachEvent("onload", function () { 
        alert("Local iframe is now loaded."); 
    }); 
} else { 
    iframe.onload = function () { 
        alert("Local iframe is now loaded."); 
    }; 
} 
document.body.appendChild(iframe); 

需要注意到的是：

• IE8也不支持iframe.onload
• Opera两者均可，所以使用此方法会绑定前者
• 即使我们不预设iframe.src = some urls，也会默认执行一次onload事件，可以通过分析 src 规避。

附测试文件：
1.iframe_ie_ugly.html
2.iframe_fixed.html
以上，我认为 ABC 中最牛的就是 B 了，这也是我标题的亮点=.=! 斯密达们认为呢？

上述文字转自 http://blog.silentash.com/2009/12/iframe-tips-abc/，感谢原作者给我提供的巨大帮助。

转载在这里与更多人分享。

——————————————————————————–

状况一：

使用 1 部 web server 与 1 部 MySQL server（两者可能同在一部主机上），而 web server 固定只对 MySQL server 上的某一个数据库进行存取动作。

因为每次存取数据库时，都是由 web 那边使用同一账号对 MySQL 上的同一数据库作业，若我们将 MySQL 与 web server 的「同时联机数」都调整为 200，就好像 MySQL 这边一直有 200 位「服务生」，随时等着接待来自 web 的 200 位「顾客」似的。而且「顾客」离开之后，「服务生」也不下场休息，时时都站在门口等着接待下一个「顾客」。

在这种情况下，您只要注意将 MySQL 的「同时联机数」调得比 web server 的高或相等，就会发现使用 mysql_pconnect( ) 是个不错的选择。
——————————————————————————–

状况二：

使用 1 部 web server 与 1 部 MySQL server（两者可能同在一部主机上），而 web server 会对 MySQL server 上的两个数据库进行存取动作。

从 web server 那边提出数据存取需求时，有时是针对第 1 个数据库（DB1），有时则是针对第 2 个数据库（DB2）。若我们也将 MySQL 与 web server 的「同时联机数」都调整为 200，这样一来，就好像 MySQL 这边有 200 位「服务生」，但同时经营两个「吧台」（DB1 与 DB2），而「顾客」可能多达 200 位。

一开始，DB1 这个「吧台」比较热门，MySQL 派了 150 位「服务生」上场接待；同样地，当「顾客」离开之后，这 150 位「服务生」仍守着 DB1 而不下场休息。后来，DB2 那边也热闹起来了，「顾客」越来越多，MySQL 得加派「服务生」上场，有几个能派？答案是 50 个！

为什么「服务生」的人力调配会捉襟见肘？那是因为 web 那边使用了 mysql_pconnect( ) 来建立联机。「服务生」一开始被指定到哪个「吧台」工作，就会持续在那边停留，绝不「转台」。
——————————————————————————–

请注意，当使用持续性的联机时，每个已建立的联机只为来自同一部 web server、使用同一组账号，且存取同一数据库的使用者服务。

如此一来，假设每部 web server 的「同时联机数」都是 200，而且同时使用 2 部 web server 会怎么样呢？从 web1 来了 50 个「顾客」，先是到 DB1 走一趟，接着再到 DB2 晃一圈，这样需要多少「服务生」接待他们？100 个（web1->DB1: 50　web1->DB2: 50）！又从 web2 来了 50 个「顾客」，也做了同样的动作（web2->DB1: 50　web2->DB2: 50）。在此之后，还有「服务生」是闲着的吗？后续若从 web1 或 web2 同时涌入多于 50 位「顾客」时，谁来应付他们？

倘若您使用的是像 Apache 这类的 multi-process web server（一个 parent process 协调一组 children processes 运作），某个 children process 建立的「持续联机」，是不能分享给其它 children process 来使用的（「服务生」只对先前接待过的「顾客」服务）。在这样的情况下，将会使得 MySQL 上闲置的 process 越积越多（很多「服务生」站在门口等着「老顾客」上门，而不理会「新顾客」）。
mysql_pconnect( ) 一定是最佳选择吗？我想未必尽然。
——– 两者之间的区别 ————–
mysql_pconnect() 和 mysql_connect() 非常相似，但有两个主要区别。
首先，当连接的时候本函数将先尝试寻找一个在同一个主机上用同样的用户名和密码已经打开的（持久）连接，如果找到，则返回此连接

标识而不打开新连接。
其次，当脚本执行完毕后到 SQL 服务器的连接不会被关闭，此连接将保持打开以备以后使用（mysql_close() 不会关闭由

mysql_pconnect() 建立的连接）。
可选参数 client_flags 自 PHP 4.3.0 版起可用。
此种连接称为”持久的”。
看到这里，写一条代码来测试一下

通过刷新网页的方式执行这条代码，发现每执行一次，mysql的进程数就增加一个。在这里我不禁有了疑问。上面说mysql_pconnect这个函

数的使用的时候，不是说”当连接的时候本函数将先尝试寻找一个在同一个主机上用同样的用户名和密码已经打开的（持久）连接，如果找到

，则返回此标识而不打开新连接”么？为什么我每刷新一次页面他就给我打开一个新的连接呢？

考虑到这有可能是PHP的bug，我到PHP的bug列表中找关于和too many connections 有关的条目。
相关的话题主要有三个，分别是

描述比较长,我就不在这里贴,具体的内容你自己去看。重点主要是”当一个进程打开一个mysql的持续连接，只要该进程还存在，这个持续

的连接就不会断开，而且每一个进程会打开一个mysql的持续连接，而不能使用其他进程打开的持续连接”。