Pity the poor IFRAME...

March 9, 2006 7:22 AM

Why exactly does everyone hate IFRAMEs so much? Is there really a good reason not to use them?

Yes, I know CSS, but I've encountered the case where I want content to appear within a certain area of a page, but there's a lot of text, so I want it to be scrollable within that area. Can I achieve this any other way (besides real frames)?

posted by ab3 to computers & internet (28 comments total)

DIVs can be scrollable. Just set "overflow:auto" in the CSS for a DIV, and set dimensions on it to whatever you want the visible portion to be, and you'll get scrollbars if the contents are bigger than the set dimensions.
posted by cerebus19 at 7:24 AM on March 9, 2006

Weren't IFRAMEs originally a Microsoft invention? If so, that'll probably be the reason. The fact that javascript asynchronous HTTP requests are also the spawn of Redmond is, curiously enough, rarely mentioned.
posted by matthewr at 7:28 AM on March 9, 2006

I think there is a place where IFrames are useful, and there are times when they are anathema. The latter cases primarily occuring where document integrity and recordkeeping are considerations. I prefer the use of <div> + CSS + AJAX—no matter who developed it—myself, but that's probably because it is a lot more like XML/XSLT. This understanding is useful in rationalizing the fact that I am, in the end, messing with document integrity by not handling it as a discrete unit.

[insert long discussion of whether the document presented to the user or the document stored on the server is the thing we should call The Document here]

cerebus answered your last question, matthewr your first, so I thought I'd take a stab at the middle one.
posted by Fezboy! at 7:47 AM on March 9, 2006

Frames always get a bad wrap because of their accessibility problems. You're not going to see IFRAME content on Lynx, on a screen reader, etc, etc. For some reason people get quite high and mighty on the whole accessibility thing, but I guess someone has to :)
posted by wackybrit at 7:50 AM on March 9, 2006

oo'er, and I forgot to add that the use of IFrames can really mangle the accessibility of a document and confuse the bejesus out of screen readers. Basically, if your only consideration is visual presentation and you could care less about any other possible use of your HTML page then there is absolutely no reason to avoid IFrames. To the degree that this case does not obtain, you would want to consider other options.
posted by Fezboy! at 7:52 AM on March 9, 2006

That, and it's two+ requests to the server where you could be making one. On slower connections (like my connection from my friend's ranch out in the boonies, where I occasionally spend the night), iFrames and other framesets can be painful.
posted by SpecialK at 7:52 AM on March 9, 2006

thus, as if on cue, I fufill wackybrit's prophecy
posted by Fezboy! at 7:53 AM on March 9, 2006

How do you do Ajax without iframes? (I mean invisible iframes, but iframes still, right?)
posted by delmoi at 8:09 AM on March 9, 2006

Just have one point to make here - search engines don't really get iframes. Some won't index it at all. Some will index it as a seperate standalone page.

cerebus19 is spot on - use a div
posted by twistedonion at 8:11 AM on March 9, 2006

Delmoi, no you can use divs. Display:none will make them invisible. Then you can redefine the visibility with Javascript.
posted by twistedonion at 8:13 AM on March 9, 2006

delmoi writes "How do you do Ajax without iframes? (I mean invisible iframes, but iframes still, right?)"

You use the DOM API to create/delete nodes on the document tree. You use the same API to unpack the information you get from the AJAX call so that you can create the content nodes. It's more or less the same as using an IFrame except that your content is integrated into the existing document instead of living in a container surrounded by the document.
posted by Fezboy! at 8:14 AM on March 9, 2006

delmoi: by using the XMLHttpRequest object instead of an iframe to fetch a request. Of course, a lot of the Ajax toolkits out there use iframe as a "fail gracefully" fallback with older browsers.
posted by furtive at 8:14 AM on March 9, 2006

I want content to appear within a certain area of a page

Some percentage of your audience will always find this attitude a problem. Think of people viewing your page on very small screens, or those (like me) who prefer windows of certain dimensions. Your frames may go out of whack immediately I resize the browser.

But with Firefox I can easily thwart your intentions, so frames no longer present the problem they did previously (right click->This Frame->Show Only this Frame).
posted by Rash at 8:16 AM on March 9, 2006

I love IFRAMES because they're the easiest to block with AdBlock in Mozilla. I wish everyone used them, especially for ads, I haven't seen an IFRAME advertisement in a long, long, time.
posted by blue_beetle at 8:35 AM on March 9, 2006

I guess I'm missing something but what about this situation, which I encounter frequently: My client has content on 4 servers. He wants his page to display content that is generated from (at least) servers 1, 2, and 3. I can do that very easily with IFRAMEs, but I don't see how to do that with DIVs.
posted by Robert Angelo at 8:36 AM on March 9, 2006

Robert Angelo writes "I can do that very easily with IFRAMEs, but I don't see how to do that with DIVs."

It is easier to do this with IFrames. It is doable using AJAX + DOM and creates a unified document. Basically

1. User requests "main" HTML file
2. Browser triggers 'onload' event
3. Embedded/linked JavaScript uses XMLHTTPRequest object to get content from other servers
4. Javascript parses content from additional servers using XPath or DOM
5. Javascript uses DOM API to generate new nodes on the document tree
6. The browser updates the display based on the changes made to the DOM

As is the case with all things Web-related, there is the easy way, the correct way, and the expedient way. Seldom do these three converge. It is up to you to weigh the costs/benefits and pick a strategy. I am trying really hard to be neutral since this is AskMe, but I would recommend considering the long-term benefits of doing things the correct way from the outset.
posted by Fezboy! at 9:15 AM on March 9, 2006

blue_beetle: ssssssshhhhhhhh! Ignorance is bliss.
posted by Fezboy! at 9:20 AM on March 9, 2006

IIRC, IFrames were a huge security risk for a while. MS invented them and tossed in a few IE security holes to encourage their development, I guess.
posted by unixrat at 9:30 AM on March 9, 2006

Is AJAX significantly harder to code than IFrames? I'm quite happy with IFrames, but I know little about javascript, DOM & XML.
posted by MetaMonkey at 11:10 AM on March 9, 2006

Rather than go all in and learn AJAX (which I *will* do when time permits) I've been using IFrames on a intranet app that I'm coding for work. It allows me some of the flexibility and real-time feedback of AJAX, but without wading into the mire of XMLHttp and all that. Since it's an internal site, I don't have to worry too much about search engine indexing or browser incompatibility.

So I guess my point is, if you're *aware* of the limitations and potential downsides of IFrames, feel free to use them as you see fit, but don't think of them as equivalent with more robust methods like divs / ajax / etc.
posted by idontlikewords at 11:26 AM on March 9, 2006

It's worth noting that iframes don't engender nearly as much hate as the good old deprecated frames that used to be ubiquitous.
posted by mikeh at 11:38 AM on March 9, 2006

here's an edge case for you: iframes can be useful because they are stateful when the user browses off the page and then clicks the back button. if you are not allowed to set cookies, iframes will preserve the trail, where dynamically swapped divs will not.
posted by macinchik at 11:58 AM on March 9, 2006

It's worth noting that iframes don't engender nearly as much hate as the good old deprecated frames that used to be ubiquitous.
posted by mikeh

It's also worth noting that frames aren't deprecated. I'm not saying anything about their relative merit - just that they are, in fact, still a valid part of the XHTML spec.
posted by robhuddles at 12:29 PM on March 9, 2006

That's a good point, macinchik and bears repeating.
posted by Fezboy! at 1:10 PM on March 9, 2006

I'd like to plug my favorite new web technique: AHAH. It's just asyncronous html, much simpler to deal with than AJAX, imo.
posted by boo_radley at 2:29 PM on March 9, 2006

I find that there is a usability problem with iframes or in general any sub-region on a page that is scrollable independantly of the main page. The issue is what gets scrolled when you use the mouse wheel, which is how I and I suspect many people do all of their scrolling. The way most browsers handle it as far as I know is that it depends on what region the mouse is hovering over -- if it's on top of the IFRAME, then that gets scrolled, otherwise, scroll the main page. This results in a horrible user experience when I'm trying to read a page and I want to scroll down, but my mouse just happens to be on the wrong region. What happens is some random unrelated region of the page gets scrolled, instead of the part of the page I care about. It makes me stop and mentally say a small little curse at the person that designed the page.
posted by Rhomboid at 2:35 PM on March 9, 2006

Fezboy! writes "Basically, if your only consideration is visual presentation and you could care less about any other possible use of your HTML page then there is absolutely no reason to avoid IFrames. "

At which point why not just admit you are not web friendly and post PDFs?
posted by Mitheral at 2:38 PM on March 9, 2006

Prior to AJAX, I used IFRAMES to import live content to my page, but I filled the page with DIVs.

The reason I did this in a roundabout manner is that IFRAMEs are more difficult to control with CSS. For example, I have a lot of pages that rely on static column headers for database driven reports. I need the scrollable area of the report (the data rows) to align perfectly with the headers, and the IFRAME's width and height isn't controllable, in relation to the rest of the page, with any consistent certainty. This problem evidences itself much more when you're trying to maintain cross-browser support.

So, my method was to use hidden IFRAMEs to drag in dynamic content, take the value of the target DIV's innerHTML attribute and make it equal to the IFRAME's body.innerHTML once the IFRAME was done loading.

I used to use a similar method back in the late 90s, when Netscape 3.0 was the standard browser (wow, imagine that). Since IFRAME didn't exist, I would use 2 Frames where the rows were specified 100%,* in the FRAMESET definition. With no borders on the Frameset, it was effectively an invisible frame.

Now, with AJAX, I bypass the IFRAME, and fill up the DIV with the content.
posted by thanotopsis at 3:30 PM on March 9, 2006