netvibes - (re)mix the web

Last week’s post about the Share tool of Netvibes Ecosystem was a prelude to another internal code update, which bears explaining here in more details.

The Share tool is a handy way of letting users get the HTML code add any UWA widget on any website, be it a blog or anything that is displayed through a browser. The nice thing is that the user can set the initial size of the widget, and moreover have the widget auto-resize itself, along with other nifty interactions.

These interactions require trickery on our part in order to be transparent to the final user. As it is, the embed code used by the Share tool has a lot in common with the UWA-IFrame method, first and foremost because the widget is displayed through an IFrame in both methods.
Relying on iframe is both simple to implement and very secure, but it calls for clever code in order to have the iframe resize itself according to the widget’s size - resizing being one of many possible communication happening between the iframe and the iframed-widget. If the UWA widget needs a bigger or lower height, it sends a resizeHeight message to the page the features the iframe, which needs to handle that resizing code accordingly.

The trick here is to make container and contained talk to each other seamlessly, which is tedious because of browser’s security settings. IFrame communication was therefore not an easy task until the recent creation of the postMessage API. Defined by the fine folks behind the HTML5 specification, its scope is to greatly ease cross-window messaging. It has since been implemented in most modern browsers, such as Firefox 3, Opera 9.50, and Webkit nightlies. Internet Explorer 8 should also let developers use it. In these browsers, we can leverage postMessage in order to enhance the UWA-IFrame code.
Sadly, postMessage is too recent for the majority of users, who rely on older versions, and this we have to cater for them too: IE6/7, Firefox 2, Safari 2/3, Opera before version 9.50… For all non enabled postMessage browsers, we use a special trick, based on a local HTML proxy. This trick is made transparent to the final user, who do not need to know how the message is getting to his page.

While it is transparent to the user, the UWA-IFrame method has to make it explicit to the developer, by design. We have therefore updated the documentation about it with a new section about the local HTTP proxy, and trimmed down some lines here and added up some there. If you are using this method to include UWA widgets on your site, you should definitely take a look at it…

This entry was posted on Tuesday, September 16th, 2008 at 4:16 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.