Ok to launch a full screen iframe widget? Vs. embedded?

Question

I am needing to a custom widget into users of my applications websites and the initial thought it that an iframe would make it SO much simpler for a few reasons:

1. I can use the custom framework built for the application which provides a ton of pre-built code and features that i'll be using in the widget and thus wouldn't have to recreate. Cross browser event handlers and prototyped objects are just a few of many examples.
2. I don't have to worry about clashing with CSS and more specifically won't have to use inline css for every dom element I create.
3. Cross domain requests are not a problem because i've already built the functionality for everything that needs to be communicated using jsonp, so don't let that be a downside for an embedded dom widget.

The idea as of right now is to write a quick javascript snippet that is essentially a button and loads a transparent iframe above the window that is full screen. This will give me control of the entire view and also allow me to write the widget just like I would any other part of the parent application. Maintaining the same json communication, using the same styles, using the framework etc. Clicking on any part of the iframe that was is not part of the widget (which will likely load centered in the middle of the screen, and be full screen if on a mobile device) will dismiss the widget and resume the user back to their normal navigation within the website. However, they can interact with my widget while its up, just like it were an embedded portion of the website that happened to load a javascript popup.

The widget itself does communication somewhat heavily with the server. There is a few requests on load, and then as the user interacts, it typically sends a request, changes the view and then wait for another response.

All that being said, is this a bad idea, or otherwise unprofessional idea? Should I put the extra work into embedding the widget directly into the hosts DOM and rewrite all the convenient framework code? I don't have a problem doing that, but if an iframe is a more appropriate choice, then I think i'd rather that. My only limitation is I need to support down to IE8, and of course, the widget needs to be viewable on both desktop and mobile, and the widget cannot be obtrusive to the clients website.

Answer 1

Some good reading from another post. Although closed, it poses some decent arguments in favor of iframes.

Why developers hate iframes?

A few points that resonate well:

1. Gmail, live.com, Facebook any MANY other major websites on the internet take advantage iframes and in situations where they are used properly...well that is what they were made for.
2. In situations especially like mine its considered a better practice to prevent any possible compatibility issues with a remote website I have no control over. Would I rather use an iframe, or destroy a persons website? Sure I can take all possible precautions, and the likelyhood of actually causing problems on another persons site is slim, but with an iframe its impossible. Hence why they were created in the first place.
3. SEO in my situation does not matter. I am simply extending a javascript application onto remote users websites, not providing searchable content.

For the above reasons, I think that taking the easier approach is actually the more professional option. Iframes in general have a bit of a misconception, I think because of their overuse in ugly ways in the past, but then again tables also have that same misconception yet believe it or not, when data is best displayed in a tabular fashion, it makes sense to use...wait for it...tables. Though we do this behind css values such as display: table-cell.

For now iframes get my vote. I'll update this answer if a little further down the development road on this project, I change my mind.