concept iframe in category javascript

This is an excerpt from Manning's book Third-Party JavaScript. Login to get full access to this book.

1.3.2. Distributing widgets as iframes

If you’re fairly experienced with web development, you might be thinking to yourself, “Isn’t it easier to distribute this widget as an iframe?” At first blush it might seem so, but there are not-so-obvious differences that make third-party scripts the better implementation choice. In order to understand why, let’s first see how you can re-create the preceding example widget using iframes.

In case you’re not familiar with them, iframes are block-level HTML elements designed to embed external content served from a URL. You could easily re-create the weather widget example using strictly an iframe element, like so:

Before the iframe can be useful, it needs to be filled with content (HTML and CSS), which you can do using one of two techniques. The most common use case is to load a remote document inside the iframe. This is done by assigning an external URL to the iframe’s src property before appending the iframe to the DOM. But even without loading a remote document, it’s still possible to embed content in iframes by using what we call src-less iframes.

When you create an iframe without setting its src attribute, you’re creating what we refer to as a blank or src-less iframe. Src-less iframes are powerful in that they contain a separate window and DOM environment, and scripts executing on the parent page can directly access these objects. That means you can populate the iframe’s contents with HTML and CSS directly from your third-party script, but still benefit from their immunity to inheriting styles from the parent page.

To gain access to the iframe’s DOM, you’ll use the iframe element’s contentWindow property. This example writes HTML directly into the src-less iframe’s body, using our old friend document.write:

var doc = iframe.contentWindow.document;
doc.write(
    '<style> /* ... */ </style>' +
    '<div>' +
    '   <h3>Mikon E90 Digital SLR</h3>' +
    '   <img src="http://camerastork.com/img/1337-small.jpg"/>' +
    '   <p>$599.99</p>' +
    '   <p>4.3/5.0 &bull; 176 Reviews</p>' +
    '</div>'
);
doc.close();

copy

You’re probably thinking to yourself, “Wait a minute—isn’t document.write bad?” Iframes are processed by the browser asynchronously, so even if there are blocking operations (like document.write) inside your iframe body, they won’t cause the browser to stop processing the parent page. There’s one caveat. Iframes can still block the parent page’s onload event, because the parent page waits for the onload event of all child windows before firing. This means that any long-loading resources inside the iframe could delay this event, possibly affecting the parent page. But fear not—calling document.close() inside the iframe after you’re done rendering forces the onload event to fire, circumventing this behavior.

You’ll also notice that, in this example, the namespaced IDs and classes we introduced in the last section are gone. This is because iframes can’t inherit style rules or be accidentally queried from the parent page, so you’re free to use whatever attributes you prefer.

Src-less iframes are a powerful way to present content in a way that can’t accidentally conflict with the parent page. But if you can access the iframe’s contents from your third-party script, so can the publisher. This means that they can write JavaScript code to access your iframe’s content and change it to their liking. That could mean injecting CSS directly into the iframe, or modifying the DOM elements in some way. Depending on the objectives of your application, you might be comfortable permitting the publisher access to your application’s contents. But if your application contains sensitive information, or is connected with a well-known brand and shouldn’t be modified, there’s an alternate approach to using iframes that makes them practically impenetrable.

Iframes and quirks mode in Internet Explorer

3.4.4. When to refrain from using iframes?

At this point, you’re probably thinking that iframes are the silver bullet to rendering defensive widget HTML and CSS. In some ways, they are—iframes provide the best protection against conflicting styles and scripts. But that protection comes at a cost. Sometimes rendering on the publisher’s DOM, for all its difficulties in maintaining consistent styles, is more appropriate. Let’s quickly look at some of these situations.

You need to render outside the iframe

One of the biggest costs of doing all your rendering inside an iframe is that you can’t render outside the iframe. There are a number of situations where rendering outside the iframe is helpful. For example, modal dialogs that overlay the entire page content aren’t possible if your rendering is restricted to the space occupied by your iframe. By the same token, tooltips, which are often positioned “on top” of elements, will be more difficult to use because they might clip the border of your iframe (see figure 3.8). In both of these cases, it’s perfectly appropriate to render directly on the publisher’s page instead. Absolute positioned elements like modals and tooltips (which are children of the body element) are far less likely to be accidentally targeted by the publisher’s styles, so this isn’t as bad as it seems.

Figure 3.8. An example of a tooltip being clipped by the iframe’s bounding box