none
Automatically adjust iframe height to height of content? RRS feed

  • Question

  • Is there any way to have an iframe automatically adjust its height to the height of the content so that scrolling the iframe would never be needed? Right now I'm just specifying a very large height (5000px) to accommodate the highest possible content.

    Thanks,

    Don Culp

    Tuesday, March 8, 2011 7:14 PM

All replies

  • Yes. Using javascript, jQuery, or one of the other frameworks you can retrieve the height of the content element you're concerned with, then set the height of the iframe. You'll have to use the src property of the iframe, and the document object of the iframe window, and things get more complicated if the height of the object in question is not explicitly set in the target document.

    But, yeah, it can be done. The better question is why it is important to avoid the vertical scrollbar, which is a standard browser UI element.

    cheers,
    scott


    Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.
    Tuesday, March 8, 2011 8:29 PM
  • Scott --

    Below the masthead and horizontal nav bar, my page has 2 iframes. The first (I1) is a small scrolling list of about 200 topics, of which about 10 are visible at any one time. The second (I2) is full width below I1. When the user clicks on a topic in I1 then the topic information is loaded into I2. (Note: in this arrangement the topic information is an include file since it is also used elsewhere on the site.) At a minimum, the height of I2 must be sufficient to allow any single accompanying graphic to be viewed completely. This means that the minimum I2 height must be about the height of the content section of the page. Then, in order for the user fully view the topic information, he must scroll the page until the top of I2 is approximately at the top of the browser window and then use I2's scroll bar to scroll the topic information itself (assuming that the topic information is too large to fit within I2). I personally dislike web sites with this double-scroll arrangement. Hence, what I have currently done is to set a very large height for I2 (to accommodate the largest possible topic information) and eliminated I2's border and scroll bar. Then the user can see the entire contents of I2 just by using the page's scroll bar. Aesthetically this is also more pleasing because I2 appears as though it is just a part of the original page, rather than being a separate iframe. However, rather than using an arbitrarily large height for I2 I would prefer to use a height that is just large enough (or slightly larger) to accommodate each topic as it is loaded.

    Of course, one way around this is to eliminate I2 and have the topic information load as a completely new page when the user clicks on a topic in I1. However, then the topic list in I1 disappears when the new page is loaded, which I don't want. The topic list is only used on this one page so it can't be part of the master.dwt.

    Is there perhaps a better way to do what I want?

    In any case, could you provide details about how to implement the javascript method.

    Thanks,

    Don Culp

    Thursday, March 10, 2011 2:39 PM
  • Of course, one way around this is to eliminate I2 and have the topic information load as a completely new page when the user clicks on a topic in I1. However, then the topic list in I1 disappears when the new page is loaded, which I don't want. The topic list is only used on this one page so it can't be part of the master.dwt.

    Is there perhaps a better way to do what I want?

    Why not do this method and just create another DWT just for these pages (you can use more than one DWT per site)? The I1 list could be in an uneditable region, so it is the same for every page, then create each page from the DWT and insert your I2 information in the editable region.

    Jim

    Thursday, March 10, 2011 3:34 PM
  • Sounds to me like it is a perfect use for an include file either server side (if it will be updated frequently) or design time if it won't and is used on only a section of the site which it sounds like might be the case.

    Includes can be used in the editable region of a site.


    Free Expression Web Tutorials
    For an Expression Web forum with without the posting issues try expressionwebforum.com
    Thursday, March 10, 2011 3:40 PM
  • Jim --

    Yes, I had considered this approach. However, keeping both dwts synchronized seems to be a drawback -- for instance, if I add a new nav button to master.dwt but forget to add it to this secondary.dwt. Is there a good way to handle this?

    Thanks,

    Don Culp

     

    Thursday, March 10, 2011 4:10 PM
  • Cheryl --

    In the content section of the page I have:

    <iframe id="I1" name="I1" src="topics.html" style="width: 219px">Your browser does not support inline frames or is currently configured not to display inline frames. </iframe>

    where topics.html is a list of topics. Each topic in topics.html has a link like:

    <a href="topic99.html" target="I2">Topic 99</a>

    where target is always iframe I2, regardless of the topic.

    When you say "Includes can be used in the editable region of a site" do you mean that it is possible to eliminate I2 altogether and have something like:

    <a href="topic99.html" target="content">Topic 99</a>

    so that the topic99 will be loaded in the content area below I1 and I1 will still be viewable?

    If not, can you explain further?

    Thanks,

    Don Culp

     


    Thursday, March 10, 2011 5:01 PM
  • Jim --

    Yes, I had considered this approach. However, keeping both dwts synchronized seems to be a drawback -- for instance, if I add a new nav button to master.dwt but forget to add it to this secondary.dwt. Is there a good way to handle this?

    I'll second Jim's suggestion to use a separate DWT for this purpose. The issue of keeping them in sync for changes in navigation is obviated if you use an include file for your navigation section in both DWTs. Update the include file, and both DWTs get the changes.

    This becomes even more convenient if you use an SSI or PHP include, because these are server-side includes. When you make changes, therefore, it is only necessary to publish the changed include file alone to the server, where it will be integrated with all of the pages which use it at render time.

    cheers,
    scott


    Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.
    Thursday, March 10, 2011 5:30 PM
  • " When you say "Includes can be used in the editable region of a site" do you mean that it is possible to eliminate I2 altogether and have something like:
    <a href="topic99.html" target="content">Topic 99</a>
    so that the topic99 will be loaded in the content area below I1 and I1 will still be viewable?"

    You wouldn't be "loading content in", you'd be linking to the topic99.html page. 

    The topic list is just an include of a list of links  in a fixed-height div with scrollbars - same look, no iframe needed.

    Put that include in each of the topic pages.  (The include lets you edit the list of topics in one place, not in each of the individual pages).

    So, topic99.html would be made from the site-wide dwt, and its content would be the topic list include followed by it's own unique content.  Repeat for all the topic pages.

    If this list of topics will change frequently, and there are lots of them, consider using a server side include rather than a design time include.  With a design time include, you need to republish all the topic pages if the topic list changes.  With a server side include you just need to publish the updated include file.  Downside: you won't see the topic list in Design View if you are using a server side include.

    • Proposed as answer by paladyn Thursday, March 10, 2011 6:56 PM
    Thursday, March 10, 2011 6:10 PM
  • Good point, Kathy. I, and I think other respondents, were looking at working with the structure he has now, but your example accomplishes the objective nicely, and with only one DWT needed.

    And I agree that a server-side include would be the best approach for the topic list. PHP includes are supported in all versions of PHP currently in common use, so version issues don't apply, and they're a snap to add in EW. All providers that I have encountered offer PHP in their plans, whether on a Linux or a Windows server. Furthermore, this lends itself to placing the main and footer navigation areas in server-side includes, as well, to accommodate edits to those areas without having to republish all attached pages.

    Your approach has the decided advantage that only individual pages (or includes) need to be republished after editing, unless the edit is to the DWT master itself.

    cheers,
    scott


    Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.
    Thursday, March 10, 2011 6:54 PM
  • Hey Scott, I was the first to suggest using Includes. Kathy picked up on the OP's response to my suggestion. <g>

    For the OP, there are a couple of options. One is to do as Kathy suggested, using an include for your list of links and having separate pages for each page also using the DWT & include.

    Another option that would require a little programming would be to pass a query string and load the file linked dynamically using another php include.


    Free Expression Web Tutorials
    For an Expression Web forum with without the posting issues try expressionwebforum.com
    Thursday, March 10, 2011 7:18 PM