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

Question

There are several problems with creating a widget for social bookmark buttons for use on other websites. We recently opened up client 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 selected items with a love of it. Using a button showing how many other people she liked.

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

There are quite complex differences between these approaches. One particularly annoying thing is the inability of the script approach to contact its popup.

Can anyone suggest a workaround for the connection between the login popup and the button. (IE, when you love something through a pop-up window, how do you update an account on a button without stopping with the same source protection).

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

These are the differences I came across: iframe vs Script

Iframe:

• Possibly pop-up message The script approach cannot communicate with pop-ups created due to the same initial limitations. However, the iframe can be in the same domain as the popup, and communicate freely. This gives a better user interface, for example, when logging in.
• Easier to develop An iframe approach is easier to develop and requires less code.
• Parallel loading in IE IE does not load count scripts in parallel, but it does it for IFRAME. Speeding up this approach.
• Independent CSS External sites do not interfere with your css buttons if you use the iframe technique. The disadvantage is that it makes things love that cannot be integrated with another site. (For example, the compact Fashiolistas button).
• The independent iframe Approach makes it very difficult for other sites to play the game that users love / love. Using 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 the use of mashups.

Script:

• Slow loading at home Creating an iframe takes much longer for the browser.
• Slow perceived load The script approach allows you to format buttons before loading data. A huge increase in perceived download speed.
• No overall functionality. Buttons do not share. Therefore, when someone enters the system for one button, it cannot be updated.

Answer 1

Of course, there is a third option, which is a hybrid between iframe and script.

You can use a script to connect to the DOM pages (gives a reward for freedom in relation to different goals) and create a hidden iframe pointing to your domain.

The script can communicate with both the current document and your use of Cross Domain Messaging and, in turn, with pop-ups using iframes as proxies.

Of course, XDM poses some difficulties, but if you use a proven solution, such as easyXDM , then it should not be a big problem.

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

Answer 2

Basically 2 questions - What is the best approach - Workaround for pop-up issues encountered by the script approach

Thanks for the tooltips! What is the underlying technology to support these cross-domain popups?

If I understand correctly your third option: - a foreign site loading our js - js, replacing dom elements - js opens a hidden iframe for your own domain

How do I open a popup that still allows me to chat with our js uploaded to someone else’s site? To do this, the popup must be created by an iframe instance? And we need a method to communicate with the iframe. I thought they were not allowed to do anything with the iframe other than setting its window.location.href. Could you explain how this works?