Widgets – iframe vs. inline

Inspector GadgetWhen writing a widget, should you use an iFrame or make the widget inline?

Widgets are small web applications that can easily be added to any web page. They are sometimes called Gadgets and are vastly used in growing number of web pages, blogs, social sites, personalized home pages such as iGoogle, my Yahoo, netvibes etc. In this blog I use several widgets, such as the RSS counter to the right which displays how many users are subscribed to this blog (don’t worry, it’ll grow, that’s a new blog ;-) ). Widgets are great in the sense that they are small reusable piece of functionality that even non-programmers can utilize to enrich their site.

I’ve written several such widgets over the time both “raw” widgets that can get embedded in any site as well as iGoogle gadgets which are more structured, worpress*, typepad and blogger widgets, so I’m happy to share my experience.

As a widget author, for widgets that run on the client side (simple embeddable HTML code) you have the choice of writing your widget inside an iframe or simply inline the page and make it part of the dom of the hosting page. The rest of the post discusses the pros and cons of both methods.

How is it technically done?

How to use an iframe or how to implement an inline widget?

Iframes are somewhat easier to implement. The following example renders a simple iframe widget:
<iframe src='http://my-great-widget.com/widgwt' width="100" height="100" frameborder='0'> </iframe>

frameborder=’0′ is used to make sure the ifrmae doesn’t have a border so it looks more natural on the page. The http://my-great-widget.com/widget is responsible of serving the widget content as a complete HTML page.

Inline gadgets might look like this:

function createMyWidgetHtml() {
 return "Hello world of widgets";
document.getElementById('myWidget').innerHTML = createMyWidgetHtml();

As you can see, the function createMyWidgetHtml() it responsible for creating the actual widget content and does not necessarily have to talk to a server to do that. In the iframe example there must be a server. In the inline example there does not need to be a server, although if needed, it’s possible to get data from the server, which actually is a very common case, widgets typically do call server side code. Using the inline method server side code is invoked by means of on-demmand javascript.

So, to summarize, in the iframe case we simply place an iframe HTML code and point the source of the iframe to a sever location which actually serves the content of the widget. In the inline case we create the content locally using javascript. You may of course combine usage of iframe with javascript as well as use of the inline method with server side calls, you’re not restricted by that, but the paths start differentially.

So what is the big deal? What’s the difference?

There are several important differences, so here starts the interesting part of the post.


iFrame widgets are more secure.

What risks do gadgets impose and who’s actually being put at risk? The user of the site and the site’s reputation are at risk.

With inline gadgets the browser thinks that the source of the gadget code code comes from the hosting site. Let’s assume you’re browsing your favorite mail application http://my-wonderful-email.com and this mail application has installed a widget that displays a clock from http://great-clock-widgets.com/. If that widgets is implemented as an inline widget the browser thinks that the widget’s code originated at my-wonderful-email.com and not at great-clock-widgets.com and so it’ll let the widget’s code ultimately get access to the cookies owned by my-wonderful-email.com and the widget’s evil author will steal your email. It’s important to realize that browsers don’t care about where the javascript file is hosted; as long as the code runs on the same frame, the browser regards all code as originationg at the frame’s domain. So, you as a user get hurt by losing control over your email account and my-wonderful-email gets hurt by losing its reputation.

If the same clock would have gotten implemented inside an iframe and the iframe source is different from the page source (which is the common case, e.g. the page source is my-wonderful-email.com and the gadget source is great-clock-widgets.com) then the browser would not allow the clock widgets access to the page cookies, nor will it allow access to any other part of the hosting document, including the host page dom. That’s way more secure. As a matter of fact, personal home pages such as iGoogle don’t even allow inline gadgets, only iframe gadgets are allowed. (inline gadgets are allowed only in rare cases, only after thorough inspection by the iGoogle team to make sure they’re not malicious)

To sum up, iframe widgets are way more secure. However, they are also way more limited in functionality. Next we’ll discuss what you lose in functionality.

Look and feel

In the look and feel battle inline gadgets (usually**) win. The nice thing about them is that they can be made to look as part of the page. They can inherit CSS styles from the page, including fonts, colors, text size etc. Iframes, OTHO must define their CSS from the grounds up so it’s pretty hard for them to blend nicely in the page.

But what’s even more important is that iframes must declare what their size is going to be. When adding an iframe to a page you must include a width and a height property and if you don’t, the browser will use some default settings. Now, if your widget is a clock widget that’s easy enough b/c you know exacly what size you want it to be, but in many cases you don’t know ahead of time how much space your widget is going to take. If, for example you’re authoring a widget that displays a list of some sort and you don’t know how long this list is going to be or how wide each item is going to be. Usually in HTML this is not a big deal because HTML is a declarative based language so all you need to do is tell the browser what you want to display and the browser will figure out a reasonable layout for it, however with iframe this is not the case; with ifrmaes browsers demand that you tell it exactly what the iframe size is and it will not figure it out by itself. This is a real problem for widget authors that want to use iframes – if you require too much space the page will have voids in it and if you specify too little the page will have scrollbars in it, god forbids.

Look and feel wise, inline wins. But note that this really depends on your widget application. If all you want to do is a clock, you may get along with an iframe just as well.

Server side vs. Client side

IFrmaes require you specify a src URL so when implementing a widget using an iframe you must have server side code. This could both be a limitation and a headache to some (owning a server, domain name etc, dealing with load, paying network bills etc) but to others this is actually a point in favor of iframes b/c it let’s you completely write your widgets in server side technologies, so you can write a lot of the code and actually almost all of it using your favorite server side technology whether it be asp.net, django, ror, jsp, struts , perl or other dinosaurs. When implementing an inline gadget you’ll find yourself more and more practicing your javascript Ninja.

What’s the decision algorithm then?

Widget authors: If the widget can be implemented as an iframe, prefer an Iframe simply for preserving users security and trust. If a widget requires inlining (and the medium allows that, e.g. not iGoogle and friends) use inline but dare not exploit users trust!

Widget installers: When installing a widget in your blog you don’t see a “safe for users” ribbon on the widgets. How can you tell if the widget is safe or not? There are two alternatives I can suggest: 1) trust the vendor 2) read the code. Either you trust the widget provider and install it anyway or you take the time to read its code and determine yourself whether it’s trustworthy or not. Reality is that most site owners don’t bother reading code or are not even aware of the risk they’re putting their users at, and so widget providers are blindly trusted. In many cases this is not an issue since blogs don’t usually hold personal information about their readers. I suspect things will start changing once there are few high profile exploits (and I hope it’ll never get to it).

Users: Usres are kept in the dark. Just as there are no “safe for users” ribbons on widgets site owners install, there are no “safe to use” sites and basically users are kept in the dark and have no idea, even if they have the technical skills, whether or not the site they are using contains widgets, whether the widgets are inline or not and whether they are malicious. Although in theory a trained developer can inspect the code up-front, before running it in her browser and losing her email account to a hacker, however this is not practical and there should be no expectation that users en mass will do that. IMO this is an unfortunate condition and I only hope attackers will not find a way of taking advantage of that and doom the wonderful open widget culture on the web.

Happy widgeting folks!

* Some blog platforms have a somewhat different structures for widgets and they may sometimes have both widgets and plugins that may correlate in their functionality, but for the matter of the discussion here I’ll lously use the term widget to discuss the “raw” type which consists of client side javascript code

** Although in most cases you’d want widgets to inherit styles from the hosting page to make them look consistent with it, sometimes you actually don’t want the widget to inherit styles from the page, so in this case iFrames let you start your CSS from scratch.

7 Responses to “Widgets – iframe vs. inline”

  1. Ran
    nice post.
    one thing to mention about this issue is load time and page delay.
    with IFrame based widgets, as they are running on an “inner window” the widget load is not disturbing the main page load. however – with inline widgets, if not implemented correctly, they can delay content loading which is sometimes… very bad!

    By Ori Lahav on May 30, 2009

  2. Hi Ori, that’s a valid point, I agree, with inline gadgets the main document may finish loading slower so this is another point in favor of iframes.

    By rantav on May 30, 2009

  3. I’m just conjuring up the idea of building a widget for my niche.

    If I produced this as an iframe widget and the widget it would simply be called a php page that I created that is the widget….

    So will the hyperlinks in that iframed php page be read by the search engine as coming from the origin of the iframe or from the page hosting the widget?

    I basically wanted to know if I got 1000 people to install my widget that had a link back to my site, would I get 1000 new backlinks or would they not be counted because they are within an iframe?

    I started to look at an inline javascript widget and it’s just too much for me!! Php seems easier.

    By Forest on Sep 24, 2009

  4. The answer re what search engines would do actually depends on the search engine itself and different engines may behave differently.
    My bet is that search engines currently don’t index javascript generated content at all (although I read that google is experimenting this) and if your widget is javascript generated, as many widgets are, then your content is not indexed no matter if it’s an iframe or not.
    If your widget isn’t javascript generated (it’s generated on the server side, such as a wordpress plugin) then my *bet* is that google would associate any iframe content to the actual page it’s included at and not to your server. Again, this is partially guess work and is really up to the search engine to decide on that.

    By rantav on Sep 26, 2009

  5. Links inside iframe (on our php page) wont be read by search engines. But link in iframe tag itself will get the google juice from client page. In short we can get get google juice for our widget page but not Homepage or any other page that we want to. Add a link outside iframe, then we get juice but in this we cant prevent user from removing our link(most precious in the world).

    By Neeraj on Jan 12, 2011

  6. Thanks for the nice post!

    I’m writing a widget these days & thought to prefer iframe method for that. But I have few questions regarding this.
    1. Is there any free reliable site where we can host our server side code & which can also handle the load? (Will Google Code or Google app engine help for this)
    2. When using iframe method, can I track the URLs of the sites who use my widget & any method to get that stats?

    Waiting for your answers. Thanks in advance!

    By Dhanika on Apr 4, 2011

  7. Google’s app engine is certainly a good option. It’s limited in some ways, so it’s not a general purpose backend, but for hosting a scalable service for a widget it’s pretty good.
    By browser’s security model, an iframe does not have access to the hosting page and this includes the URL of the hosting page. You can, however, pass that URL as you call your widget, e.g instead of simply embedding an iframe with a link to your widget, embed a script which builds this iframe and passes the link of the hosting page to it.

    By Ran Tavory on Apr 4, 2011

Sorry, comments for this entry are closed at this time.