Embeding content on your web pages -- iframes vs native content?

[mouser]

I've been working on a web application project (in collaboration with dc member JavaJones) recently that i hope to unveil for DC in the next month or two.

One key aspect of it is that people can embed content from the web service on their own web pages (e.g. Widgets).

If you look around at how "foreign" content is embedded on web pages, there are really 2 main ways, one is using an iframe to just load a page from another site into an area on the current page.  Google Ads are a good example of this.

The other way is to have a local script which acts as a kind of "proxy" and serves up the scraped data from the remote site.  There are RSS reader widgets that work like this.

I have always disliked iFrames, for one reason because the content can't be easily resized on your page.

But i'm starting to ask myself how common it is to have resizable sidebars.. and if the container isn't going to change size, maybe it doesn't matter so much.

So i'm wondering if people have other experiences embedding content on their pages using a widget like system, and if they have positive or negative views about using iFrames vs. the alternative methods.

Thoughts?

[rgdot]

One site I set up with a CMS needed to include a third party poll script that wouldn't play nice with the CMS so I had to add it to the page within an iframe. Otherwise I see no reason to stop disliking iframe.

[Veign]

Depends on what is being served up.  For Google Ads it makes perfect sense to provide fixed sizes, nothing more.  If it were a Google Map then offering resizing options is a must.  What it come down to is content being embedded - it should dictate the method.

For a recent project of mine I used an iframe method since it was dead simple to implement.

Sample:
http://openmenu.com/api/embed.php?menu=9529

Basically I made it customizable.  I would rather implement a widget/JS method but time isn't on my side.  Maybe we can compare notes at some point.

[mouser]

truth be told i've already implemented my system which supports both iframe and a local caching/proxy method.  the local caching proxy is important for me if for no other reason than it can relieve bandwidth on the main central server.

my dilemma is mainly that i started out thinking how much i hated iframes and how i couldn't wait to write this alternative method, but after doing it and all the work involved, i find myself having a harder time than i thought justifying the benefits to someone of being able to avoid using the iFrame method.

[Stoic Joker]

I don't think I've ever used an iFrame for anything I didn't end up regretting.

So, I'll vote script/proxy.

Granted most of my stuff pulls data from a SQL db and dumps it on a page as a report.

[PPLandry]

If the content formatting does not contain any CSS specific styles, putting the content inside a <div> </div> works quite well, and it does auto-size correctly (unlike iframe)

FYI, one way to auto-size iframes, it is to run a script to size it once loaded, setting the height property to the document height

[Veign]

You can't embed content in a DIV from a 3rd party website.

mouser,
Are you looking to get analytics from the page its being embedded on?  Are you interacting with the host page in any way?  Does an iframe version work the same as the more complex JS version?

[mouser]

Are you looking to get analytics from the page its being embedded on?  Are you interacting with the host page in any way?  Does an iframe version work the same as the more complex JS version?

i'm actually pretty proud of how i coded it -- i created code to render the results which is shared between both the server script and the local script.  the server code is actually driven by a drupal cms, but the rendering code has no drupal specific stuff.  part of why i did that is so that the local widget script can interact with the data in various ways as well (ie. pagination, etc.) -- it's not just grabbing and caching a simple html contents page.

if the user wants to use iframe version they just use that (and i can even have a lightweight non-drupal server script create the data from the request).

if the user wants to use a non-iframe local widget, then the rendering code is invoked by a local script on the machine serving up the page, using a kind of proxy cache that only periodically needs to get new data from the remote server.  i make use of several mechanisms to keep bandwidth minimum until content actually changes (i use Conditional Get and keep track of when data has changed, etc.).

part of why i've gone to so much trouble to avoid an iframe solution is that this is meant to be something that could theoretically be on huge numbers of pages serving of a huge amount of bandwidth constantly, and using an iframe solution would mean that my server would have to fulfill all of those requests live.  the way i have it now it's almost no bandwidth/cpu at all on the main remote server -- just the occasional query to ask whether the cached content has changed (and the answer is almost always no).

the cache proxy system also downloads and replicates image files automatically since some of the widget content refers to images on the main server, which again i don't want to have to bear the burden of serving up.

one major advantage of this over iframes is that the widget will work fine if the main server goes does completely.. it simply serves up the last good cached version of the data.

ps.
there is an existing php script that does a fair amount of what my code does and is pretty generic; it doesn't do conditional get but it's otherwise pretty good: http://www.troywolf.com/articles/php/class_http/  you'll also find that some rss widget scripts do a similar thing regarding caching, which let's them solve the "same origin policy" security lockdown on webpage javascript (which is a pain in the ass and clearly not stopping anyone from doing this, just making it harder).

[PPLandry]

You can't embed content in a DIV from a 3rd party website.

Absolutely true, my mistake 

[Veign]

@mouser - good explanation.  Once I get to the point of moving forward with a JS version (for the same benefits you described) I will be in contact

[olderthandirt101]

Word Press has an embed iframe plug-in available that allows resizing.Using iframes to embed anything that you wish the search bots to read is fruitless unless you add your own content such as a review, outside the iframe .
Cacheing your content in gzip format in your database is always a good idea to save bandwidth.Again,WP has a plugin for that also.
Using php plugins for images, sound, or video ,whether streaming from sites like Youtube or your own site server simplifies things.I have used FLV Gallery,Next Generation Gallery,Fancy Box and Multibox..Resizing has never been much of a problem esp. with embed codes. For example, FLV Gallery allows presizing of a single video with subsequent videos displayed as thumbnails just like on Youtube,all with a simple shortcode in a page or post .If your intention is to use it for a sidebar or widget then the global presize maximum width is 300px.

[CWuestefeld]

On the web site that I'm responsible for at work, I'll go to the ends of the Earth to avoid an IFRAME. A client-side script to pull in content from a foreign site is slightly preferable, but still not good.

The thing is, I'm responsible for ensuring the security of my users. When retrieving IFRAME content from a foreign server, I'm surrendering all control to that foreign server, but my users don't know where it's coming from, nor how trustworthy they are.

The AJAX solution is better, because it's not taking raw HTML. But at a minimum, it's still a privacy exposure in that it reveals to the foreign server who my customers are, and what content they're interested in.

Of course the "do the right thing", wanting to protect my customers, is the main thing. But even if it were not, some of our customers have placed restrictions in our contract that prevent me from doing this. So when it does occur on our site, I need to have behavioral switches in our code to disable it for customers that won't allow it. And where it can be allowed, I need NDAs and indemnification from the foreign server to keep me and my customers safe.

My preferred solution is for you to give me a web service. I can call your service from our web servers, acting as a proxy for the user, and expecting back data as opposed to raw HTML. I can then embed that into the pages as I see fit, with a much greater feeling of safety.

Of course, your users may not be so exacting, or have so much to protect. But without knowing what content you'll be dealing with, who knows...

[Codebyte]

Mouser,

To answer your original question concerning the much debated "iframe or direct content injection" topic, let me first begin by explaining my own personal experiences.

While at work, I use a total of 3 methods for content injection and asychronous javascript and xml (ajax) calls. The three methods include:
1. Getting a script by creating a new dom element and injecting it somewhere to the page  which forces the clients browser to go get the data. I use this method the most to call php scripts that handle content and echo out javascript. It's ideal for dealing with data clientside (nothing important like passwords etc) but still being able to use server side code because php has access to mysql which can cache your data among other endless possibilities.
2. the traditional ajax methods - creating a new httprequest. i rarely ever use this method anymore.
3. using a combo of YQL (Yahoo Query Language) and #1. - i use this approach the most to scrape data from any web page i need. Yahoo actually caches the results for you which result in faster data returns.

Now you'll notice that none of my methods include iframes. My personal opinion concerning iframes is that they are deprecated. Tons and tons of headaches are created by using methods that include iframes. When traversing the DOM, iframes create more work than necessary. On another note... Iframes are absolutely required when uploading files without reloading a clients browser.

It all depends on your objective... Let me propose an example:

You have a personalized dashboard system for when a customer/user logs in. They have the ability of customizing what "widgets" they want. One customer in particular specifies he wants te latest tweets to display in a beautifully skinned widget box that you've created. the only problem is that you need to get his tweets.

in this example, i would create a few javascript functions to execute when the page is rendering that show a loading bar, use method #1 to create a script element that calls a php file i created to check the last time this users tweets were grabbed. if less than 1 hr ago, i would use mysql to grab the cached tweets and eliminate the extra server connection to twitter (which is overloaded constantly and could result in a timeout or hang.) if the users tweets were grabbed more than 1 hr ago, php can use cURL to grab the new tweets from the server and echo out an object response using JSON so that you can populate the widget with the data the user needs in an easily accsssible manner.

Anyways, let me know if you have questions. I'm uncomfortable typing from my iPhone and can provide more help at a better hour tomorrow