Thursday, 22 November 2012

iFrames in 2012. Really?

It is fashionable for web programmers to hate iFrames. I very recently heard some reasons why you might wish to use one. For a social widget placed on a CMS driven page the benefits of an iFrame were:
  • CSS sandboxing
    Iframed content is guaranteed to be unaffected by any styles on the parent page.
  • JS sandboxing
    Similarly, iframes don't inherit a polluted global scope or adjustments to object prototypes.
  • Cross Domain Simplicity
    If the social service runs off a different domain to the parent website, the iframe content (if also hosted on the other domain) will not suffer any cross domain issues.
Let's have a look at each benefit in turn, starting with CSS sandboxing.

The primary purpose of CSS is that it cascades. This is what it was designed for and is generally a good thing. This is easily worked around by making selectors more specific, usually by prepending a classname as a namespace in front of the rules.

However, iframe content that ignores the parent site's CSS required the creation of another set of rules which are separate but in all likelihood highly similar. Any changes to the design or UX of the main site will require developers making changes in two places. 

JS Sandboxing. The main app may have a bunch of stuff sitting on the global scope. It may also have done some things to the prototypes of common objects like Array. This pattern doesn't appeal to everybody, but there is no obligation to use any prototypal enhancements. If the parent app is doing something literally insane on an object prototype then its probably best to tell the developers, rather than working around the problem. 

Things are also messier if the iframe needs to communicate with its parent, even with window.postMessage. Primitives may be passed easily enough, but object instances or events will confuse IE7.

Cross domain issues. Adding a rewrite rule in the Apache / server on nginx etc to point to the other service from the main domain(s) is the way to go. iframes are notorious for introducing their own cross domain issues.

There are some good reasons to use iframes, particularly for serving content/adverts on third party sites over which there is genuinely no control (the HTML5 folks went so far as to reestablish the iframe in the spec: http://dev.w3.org/html5/spec/single-page.html#the-iframe-element). 

In short, if the integration takes place within a single organisation, these benefits only increase the technical debt for everybody. Code may be more complex and harder to maintain. The user's browser will consume more memory due to double evaluations. Sizing and scrolling inconsistencies may crop up across different mobile platforms. iframes are unfashionable for good reason.

No comments:

Post a Comment