Javascript widget (similar to Facebook Like) script vs Iframe approach

Question

When building a social bookmarking button widget for usage in other websites there are a few challenges. We just recently opensourced the clientside aspects of this. (blog post here: http://www.mellowmorning.com/2010/08/03/creating-your-own-diggfacebook-liketweetmeme-button/)

Basically the goal is to replace the chosen elements love it With a button showing how many other people loved it.

There are two approaches to this. - replace the A with html (script approach) - replace the A with an iframe (iframe approach)

There are rather complicated differences between these approaches. One particularly annoying is the inability for the script approach to communicate with its popup.

Can anyone suggest a workaround to communicate between the login popup and the button. (IE. when you love something through the popup?, how do you update the count on the button, without being stopped by same origin protection..)

Which approach do you recommend. Iframe or Script and why?

These are the differences I encountered: Iframe vs Script

Iframe:

• Popup communication possible The script approach cannot communicate with popups it creates due to the same origin restrictions. The iframe however can be of the same domain as the popup and freely communicate. This gives a better user experience when for instance logging in.
• Easier to develop The iframe approach is easier to develop and requires less code.
• Parallel download in IE IE doesn’t download the count scripts in parallel, but it does do so for the IFRAMEs. Making this approach somewhat faster.
• Independent CSS External sites don’t interfere with your button’s css if you use an iframe technique. The disadvantage is that it makes things likes hovers impossible to integrate with the other site. (For example Fashiolista’s compact button).
• Independent The iframe approach makes it very hard for other sites to game the users like/love action. With a script approach a foreign site can simply call your javascript to fake someone loving the product. This freedom can be abused but also allows for mashups.

Script:

• Slower dom load Creating iframes takes a lot more time for the browser.
• Slower perceived load The script approach allows you to format the buttons before the data is loaded. Vastly increasing the perceived load speed.
• No shared functionality Buttons can’t share functionality. So when someone logs in for one button its is not possible to update the others.

Answer 1

There is of course a third option too, which is a hybrid between the iframe and the script approach.

You can use script to hook into the pages DOM (gives a loot of freedom with regards to different uses), and to create a hidden iframe pointing to your domain.

The script could communicate both with the current document, and with yours using Cross Domain Messaging and in turn with the popups using the iframe as a proxy.

Of course, the XDM does impose some difficulties, but if you use a proved solution like easyXDM, then it shouldn't be much of a problem.

Here is an example that shows how to interact with a popup.

Answer 2

Basically 2 questions - Which is the best approach - Workaround for the popup communication difficulties the script approach faces

Thanks for the popup information! What is the underlying technology to support these cross domain popups?

If i understand your third option correctly: - foreign site loading our js - js replacing dom elements - js opening hidden iframe to own domain

How do I then open a popup which still allows for communication with our js loaded into the foreign site? For that the popup would need to be instantiated by the iframe right? And we would need a method to communicate with the iframe. I thought im not allowed to do anything with the iframe except setting its window.location.href. Could you explain how that works?