Web Authoring Techniques: IFrame Adaptive height

Transferred from: http://www.enet.com.cn/article/2012/0620/A20120620126237.shtml

Through the Google search iframe adaptive height, the results of more than 5W, the search iframe highly adaptive, the results of more than 2W.

I turned the front dozens of, planing a lot of reprint, there are 35 original. And this several original inside, basically only talk about how to adapt to static things, is not considering the JS Operation Dom, how to do the dynamic synchronization problem. In addition, in terms of compatibility, the study is not thorough.

In this article, I hope to do some further in these two aspects.

Perhaps someone has not come into contact with this problem, first explain, what is adaptive height bar. The so-called IFRAME adaptive height, is, based on the interface aesthetics and interaction considerations, hiding the IFrame border and scrollbar, so that people do not see it is an IFRAME. If the IFRAME always calls the same fixed height page, we can write the dead iframe height directly. If the IFRAME is to switch pages, or if the page is included to do DOM dynamic operation, then the program needs to synchronize the iframe height and the actual height of the included page.

By the way, the IFRAME in the forced time to use, it will bring too much trouble to the front-end development.

There are roughly two traditional practices:

Method one, after each contained page is loaded in its own content, the execution JS gets the height of this page, and then to synchronize the height of the iframe of the parent page.

Method Two, execute JS in the OnLoad event of the main page IFRAME, to get the height content of the included page, and then to synchronize the height.

In terms of code maintenance, method Two is better than method one, because method one, each included page to introduce a section of the same code to do this thing, create a lot of copies.

Two methods are only deal with the static thing, is only in the content loading time execution, if JS to operate the DOM caused by the height changes, are not very convenient.

If you do a interval in the main window, constantly to get the height of the included page, and then do synchronization, is not convenient, but also solve the JS operation Dom problem? The answer is yes.

Demo page: Main page iframe_a.html, including page iframe_b.htm and iframe_c.html

Main Page code example:

function Reinitiframe () {

var iframe = document.getElementById ("frame_content");

try{

Iframe.height = Iframe.contentWindow.document.documentElement.scrollHeight;

}catch (ex) {}

}

Window.setinterval ("Reinitiframe ()", 200);

If the/script> has been implemented, will efficiency be problematic?

I did the test by opening 5 windows (IE6, IE7, FF, Opera, Safari) to execute this code, without any effect on the CPU, or even 2ms, and no impact (basically maintained at 0% occupancy rate).

The following is a discussion of the compatibility of the browser, how to get to the right height, mainly on the Body.scrollheight and documentelement.scrollheight two worth comparing. Note that this article uses this DOCTYPE, the different DOCTYPE should not affect the result, but if your page does not declare DOCTYPE, it is the first to add a bar.

! DOCTYPE HTML PUBLIC "-//w3c//dtd HTML 4.01//en" "Http://www.w3.org/TR/html4/strict.dtd" and append the following test code to the main page to output these two values, code example:

Check Height

function Checkheight () {

var iframe = document.getElementById ("frame_content");

var bheight = iframe.contentWindow.document.body.scrollHeight;

var dheight = iframe.contentWindow.document.documentElement.scrollHeight;

Alert ("Bheight:" + bheight + ", Dheight:" + dheight);

}

The page/script> is loaded, you can switch an absolutely positioned layer to make the page dynamic change. If the layer expands, the height of the page is high. code example:

Toggle Overlay

/div>

Div style= "Height:160px;position:relative"

div id= "Overlay" style= "position:absolute;width:280px;height:280px;display:none;" >

/div>

Script Type= "Text/javascript"

function Toggleoverlay () {

var overlay = document.getElementById (' overlay ');

Overlay.style.display = (Overlay.style.display = = ' None ')? ' Block ': ' None ';

}

The test values for the above code in each browser are listed below/script>:

(Bheight = body.scrollheight, dheight = documentelement.scrollheight, red = error value, green = correct value)

/layer hidden when layer expands bheight dheight bheight dHeightIE6 184 184 184 303ie7 184 184 184 303FF 184 184 184 303Opera 181 181 300SAF Ari 184 184 303 184 for the moment it ignores opera's problem of 3 pixels less than others ... It can be seen that if there is no absolute positioning of things, two values are equal, whichever does not matter.

But if there is, then the performance of the various browsers is not the same, the single-take which value is not correct. But you can find a rule, that is, to take two worth of the maximum value can be compatible with each browser. So our homepage code is going to be transformed into this:

function Reinitiframe () {var iframe = document.getElementById ("frame_content");

try{

var bheight = iframe.contentWindow.document.body.scrollHeight;

var dheight = iframe.contentWindow.document.documentElement.scrollHeight;

var height = Math.max (bheight, dheight);

Iframe.height = height;

}catch (ex) {}

}

Window.setinterval ("Reinitiframe ()", 200); In this way, the compatibility issue is basically resolved. By the way, not only the absolute location of the layer will affect the value, float will also result in two value differences.

If you show the demo, you will find that, in addition to IE, other browsers, when the layer is expanded and then hidden, the height of the value is maintained in the expanded height of 303, rather than the real value of hiding back 184, that is, long after the contraction will not go back. This behavior can also occur between the different contained pages, when switching from a high page to a low page, the height is still the high value.

It can be summed up that when the iframe form is higher than the actual height of the document, the height is the height of the form, and when the form height is lower than the actual document height, the actual height of the document is taken. Therefore, try to set the height to a value that is lower than the actual document before synchronizing the height. So, in the iframe add onload= "This.height=100″, let the page load the time to be low enough, and then sync to the same height.

This value, in the actual application of the decision, short enough, but not too short, or in the FF and other browsers will have a noticeable flicker. Dom operation when the main page can not listen to, only the DOM after the operation of the height has been smaller.

In one of my actual projects, the tradeoff between cost and benefit, I didn't do this, because each DOM function inserts this code, the price is too high, in fact, the layer is not shrinking back and not so deadly. Including the demo, and didn't do it. If the reader has a better way, please let me know.

Here is the code for the final page:

Script Type= "Text/javascript"

function Reinitiframe () {

var iframe = document.getElementById ("frame_content");

try{

var bheight = iframe.contentWindow.document.body.scrollHeight;

var dheight = iframe.contentWindow.document.documentElement.scrollHeight;

var height = Math.max (bheight, dheight);

Iframe.height = height;

}catch (ex) {}

}

Window.setinterval ("Reinitiframe ()", 200);

/script>