ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Other Software > Developer's Corner

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

(1/3) > >>

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.

Navigation

[0] Message Index

[#] Next page

Go to full version