Widgets are small web applications that can be easily added to any network of pages. They are sometimes called gadgets and are widely used in growing a number of web pages, blogs, social sites, personalized home pages such as iGoogle, my Yahoo, netvibes and etc. In this blog, I use several widgets, such as the RSS counter on the right, which shows how many users subscribe to this blog (don’t worry, itll grow, thats a new blog ;-)). Widgets are great in the sense that they are small reusable functionality that even non-programmers can use to enrich their site.
I wrote some of these widgets during a time when both raw widgets that can be embedded in any website, as well as iGoogle gadgets that are more structured, exciting *, widgets like and blog, so Im happy to share my experience.
As the author of the widget, for widgets executed on the client side (simple embedded HTML code) you have the choice to write the widget inside the iframe or just embed the page and make it part of the hosting page dom. The rest of the post discusses the pros and cons of both methods.
How is this technically done? How to use iframe or how to implement a built-in widget?
Ifragms are a little easier to implement. The following example creates a simple iframe widget: http://my-great-widget.com/widgwt 'width = "100" height = "100" frameborder =' 0 '>
frameborder = 0 'is used to make sure ifrmae has no border so it looks more natural on the page. http://my-great-widget.com/widget is responsible for serving the widget as a full HTML page.
Built-in gadgets may look like this:
function createMyWidgetHtml () {return "Hello, Widget World"; } document.getElementById ('myWidget'). innerHTML = createMyWidgetHtml (); As you can see, the createMyWidgetHtml () function is responsible for creating the actual contents of the widget, and do not necessarily talk to the server to do this. In the iframe example, there must be a server. The built-in example does not have to have a server, although if necessary, you can get data from the server, in fact this is a very common case, widgets usually call the server side code. Using server-side embedded code is invoked using on-demmand javascript.
So, to summarize, in the case of an iframe, we simply put the iframe of the HTML code and point the source of the iframe to a localized location that actually serves as the content of the widget. In the inline case, we create content locally using javascript. Of course, you can combine the use of iframe with javascript, as well as the use of the built-in method with calls on the server side, you are not limited to this, but start the path in different ways.
So what's the deal? What's the difference? There are several important differences, so the interesting part of the post begins here.
Security. IFrame widgets are more secure.
What risks do gadgets impose and who is actually at risk? the site user and site reputation are at risk.
When using the built-in gadgets, the browser believes that the source of the gadget code comes from the hosting site. Suppose you are viewing your favorite email application http://my-wonderful-email.com and this mail application has installed a widget that displays the clock from http://great-clock-widgets.com/ . If these widgets are implemented as a built-in widget, the browser believes that the widget code originated from my-wonderful-email.com, and not on great -clock-widgets.com, and therefore itll let the widget code eventually get access to cookies, owned by my-wonderful-email.com and the evil widget author will steal your email. address. It is important to understand that browsers do not care about where the javascript file is located; while the code runs on the same frame, the browser considers the entire code as the source g in the domain frames. So, you, as a user, were hurt by losing control of your email and my wonderful email gets hurt, losing your reputation.
If the same clock were implemented inside the iframe and the iframe source is different from the page source (which is a common case, for example. The page source is my-wonderful-email.com and the gadget source is great-clock-widgets.com), then the browser would not will allow clock widgets to access page cookies and not allow access to any other part of the hosting document, including the page dom host. It is much safer. In fact, home pages such as iGoogle do not even allow built-in gadgets, only iframe gadgets are allowed. (Built-in gadgets are allowed only in rare cases, only after a thorough check by the iGoogle team to make sure theyre not malicious)
To summarize, iframes are safer. However, they are also more limited in functionality. Then discuss well what you are losing in functionality.
Look and Feel In the look and feel of battle, built-in gadgets (usually **) win. The best part is that they can be made to look like part of the page. They can inherit CSS styles from the page, including fonts, colors, text size, etc. In an iframe, OTHO needs to define its CSS from the bottom, so it's pretty hard to combine them well in page
But more importantly, iframes must declare that their size will be. When adding an iframe to the page, you must enable the width and height property, and if you do not use it, the browser will use some default settings. Now, if your widget is a clock widget that is fairly easy to b / c, you know what size you want, but in many cases you don’t know in advance how much space your widget is going to take. If, for example, you create a widget that displays a list of some kind, and you do not know how long this list will be or how wide each element will be. Usually this is not a big deal in HTML, because HTML is a declarative language, so all you have to do is tell the browser what you want to display and the browser will have a reasonable layout for it, however with an iframe this is not so; ifrmaes browsers require that you specify exactly what the size of the iframe is, and he himself will not understand it. This is a real problem for widget authors who want to use iframes - if you require too much space, there will be voids on the page, and if you specify too few for the page to have scroll bars, God forbids.
Look and feel wise, inline wins. But note that this really depends on the application of your widget. If all you want to do is watch, you can get along with an iframe just as well.
In relation to the server side and the client side, IFrmaes needs to specify the src URL so that when you implement the widget using iframe you must have the server side code. This can be both a limitation and a headache for some (owning a server, domain name, etc., engaged in downloading, paying bills on the network, etc.), but for others this is actually a point in favor of iframes b / c it allows you to completely write your widgets in server technologies, so you can write a lot of code and almost all of this using your favorite server-side technology, be it asp.net, django, ror, jsp, struts, perl or other dinosaurs. With the implementation of the built-in gadget, you are more and more javascript Ninja.
What is a solution algorithm? The authors of the widget: if the widget can be implemented as an iframe, they prefer an iframe just to maintain user safety and trust. If the widget requires an attachment (and the environment allows, for example, not iGoogle and friends) use the built-in ones, but decide not to use the trust of users!
Widget installers: when you install a widget on your blog, you don’t see the "user-friendly" feed on widgets. How can you tell if a widget is safe or not? There are two alternatives that I can offer: 1) trust the provider 2) read the code. Either you trust the provider’s widget and install it anyway, or you took the time to read its code and determine whether it is trustworthy or not. The reality is that most site owners are not bothered by reading the code or even not aware of the risk they pose to their users, and therefore widget providers blindly trust. In many cases, this is not a problem, since blogs usually do not contain personal information about their readers. I suspect things will start to change if there are several high-profile exploits (and I hope he never gets to it).
Users: Usres are stored in the dark. Just as there is no "safe for users" on which the owners of widget sites are installed, there are no "safe to use" sites and mostly users are stored in the dark and have no idea, even if they have technical skills, regardless of whether they are the site uses widgets, regardless of whether the widgets are built-in or not; whether they are malicious. Although a theoretically trained developer can check the code up before launching it in his browser and losing her email address to a hacker, it’s not practical and you should not expect users to do so in droves. IMO is an unfortunate state, and I hope that the attackers will not find a way to take advantage of this and doom the beautiful open culture of widgets on the Internet.
Happy people voting!
- Some blogging platforms have slightly different structures for widgets, and sometimes they can have both widgets and plugins that can correlate in their functionality, but in connection with the discussion here, Ill lously use the term widget to discuss the "raw" type, which consists from client-side javascript ** Although in most cases you want widgets to inherit styles on the hosting page so that they look compatible with it, sometimes you really don’t want the widget to inherit styles from the page, so in this case ae iFrames allows you to start your CSS from scratch.