I'm building a widget, and I've been using iframes to present content within it. At some point, I might start serving third party HTML and JS, so I thought iframes would be a good idea.
It does make the widget javascript a little more complicated, and I'm concerned that this might not be the best implementation.
Do you have any advice? It would be a huge help to hear what other people think about iframes.
No, nothing wrong with iframes. Iframes are probably a better idea if you're going to start serving third party content.
The upcoming HTML5 spec also plans to build more security features into iframes for situations like this, so I would consider it good practice to use them now also.
Depends what the widget does. Iframes have their place, but they do cause few layout headaches (not to mention making your js more complicated) so most people tend to avoid them unless absolutely necessary..
One thing I discovered recently is that .aspx pages embedded inside iframes sometimes have problems with losing cookies, which led to lost session state in an application I was involved with.
For me, it was in a scenario where a different development shop was consuming one of my .aspx pages in their own page. This means we were on seperate servers, which may or may not be salient.
Apparently this was caused by the parent page rejecting cookies for the child page... As goes the session cookie, so goes the session.
The specific mechanics of how this works are a little involved: More Details
This problem did not impact FireFox, but it did show up in IE7 and it was a real mystery for a few hours.
Also, I have to contradict the article I linked to above on one point. The article says that you don't get this if the containing page is also an .aspx... In this case, that was not true because both pages were .aspxs.
That casts some doubt on everything else the article says about this situation, but it did lead to a resolution, so that's something as well.
As the article suggested, I put in the following code, which injects a p3p (Privacy Preferences Project - I had never heard of it) header in the page's Init event:
HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""")
...And that fixed the problem.
iframes, like frames, are just controls to use for the task at hand. As such, it is neither good nor bad in itself, but could be good or bad based on the task at hand and the client's requirements. As far as I know, all modern browsers (and non-linux users) will be able to "see and consume" iframes without a problem.
A good option is to use the overflow CSS property. The default value is visible but you can set it to hidden, scroll or auto. I would use auto in your case. If your content gets too big it will look like you have an iframe but it is still right on the page.
see: overflow property
Not necessarily, as long as the content within the iframe is predictable.
Before XMLHTTPRequest became widely used, people were using a combination of JavaScript and iframes to serve up content in a dynamic fashion without doing full page refreshes.
There's lots of information about developing sites this way so you should have a relatively easy time of it finding workaround to a lot of the snags that you are likely to hit.
The one thing that I have found to be a pain is cross-domain use of JavaScript in iframes. If the page you embed in the iframe is from a different domain than the "parent" page, browsers have security restrictions against letting you access one from the other. The trick is for both pages to declare
document.domain = 'somedomain.com';
There's plenty of stuff on the Web about this kind of workaround.
Good luck!
Personally, I'd avoid it if you can without too much hassle. Using Javascript (or AJAX if you need to load them dynamically), you can quite easily just use a div and change the contents as necessary - in some cases this will give you much more flexibility and will simplify your JS, especially if there's a lot of interaction between your widget and the rest of the page.
That said, I'd investigate both options, and if the JS path seems too tricky or complicated, just go with iframes.
There is only one "really bad" thing with them that I'm aware of.
If your 3rd party does some JavaScript, that attempts to modify their DOM a bit too early... IE6 and IE7 will throw the oh so unhelpful "Operation Aborted" error, then blank out not only the iframe, but the entire surrounding page. (e.g. your site appears down)
It isn't fixed in IE8, but the crash is better handled.
In my experience, iframes are either hacks or time-savers - make sure that if you're using them they're neccesary for those reasons. If you have control over the content (or can gain control through mirroring or scraping) you should consider using AJAX or server-side includes to pull external data onto and push it off of the page - it'll end up being more flexible, more robust, and easier to manage in the end.
Technically there is nothing wronger with iFrame that with alternatives. But semantically, there are evil.
The Web is based on HTTP, a protocol that says a given URL will always leads to a unique ressource.
Using iFrame, you just serve several ressources melted in a web pages behind one URL for all of them. If you have concerns about how the Web should grow, it's troublesome. What's more, for the search engine robots, it's tricky.
I'm going to disagree with the majority and say that yes, iframes are an absolutely terrible idea. Anyone that has worked within the Web Design community for a while will agree that iframes are pure evil and should be avoided unless ABSOLUTELY essential.
My reasons for believing that they are bad is because they break the navigational pattern of a web page. By using an iframe you can effectively break the back and forward buttons on browsers and confuse your users. It breaks the entire idea behind the HTTP protocol; that a URL will always lead to a unique location. If the iframe were a horse it would've retired long ago. There are other ways to serve content dynamically and these should be used instead.
If you're creating a widget then the immediate concerns with using iframes disappear (bad for Search Engines, bad for Bookmarking, etc), but either way content would be better served dynamically or even in a new window rather than in an iframe.
Iframes are not evil they are just another tool like anything else and to determine their merits you have to determine the context in which they will be used. Google Image Search, and several other high profile sites, use iframes for limited purposes.
In general I find they are used for branding or to enable a user to return to a site that redirects the user off site.
Note, if you are using cross domain iframes e.g. an iframe that refers to a domain outside where the page is being served you are limited by design for security reasons and cannot access through javascript the internals of a DOM outside the domain it is associated with.
Also please note many sites prevent their site from being embeded and will stripe the iframe off (redirecting the top url to their domain).
Re: "the entire idea behind the HTTP protocol; that a URL will always lead to a unique location"
I serve my entire CMS from the same URL for security and scaleability (using mostly POST instead of GET parameters). I don't want secure content visible without authentication, and a dispatch system makes development easier for me as I don't have to worry about authentication for every new page.
Also, for some applications SEO is not applicable (such as for web-based ERP).
I use an iFrame for serving content from a PHP generated assembly tree. I don't want the tree (and node visibilities) refreshed whenever the user wants to view details for a part/assembly.
There are several usability and accessability issues with iframes. Some browsers and screenreaders can not display iframes, so you should provide alternative content:
<iframe src="content.html">
<p>
This content will only be displayed by browsers that do not support
iframes. You should provide a link to the content, or in your
case an alternative way to use your widget.
</p>
</iframe>
If you start serving third party content, you should watch out for the iframe grabbing focus after it has finished loading. While a minor annoyance for regular users, it can be very confusing for users browsing with screenreaders.