In Defense of the iFrame
Like Comic Sans, the iframe is one of those things we just know we’re supposed to hate, even if we’re not sure why. We get swept up in a collective prejudice so old we don’t think to question it. If you Google “iframes are good” (go ahead, I’ll wait), the top titles returned are things like “‘Are iframes considered ‘bad practice’?”, “The iFrame is Evil!”, and “4 Reasons You Need to Stop Using iFrames.” One programmer on Stack Overflow wished to know whether using an iframe qualified as “a disaster” that would put him in poor standing with his boss.
Just to clarify, we’re talking about a HTML element here, not a zero-day exploit. Comic Sans, often described as “the most hated font in the world,” is also just a tool that has come under fire for having been misused. Comic Sans was developed by Microsoft for child-oriented contexts like comic strips and birthday cards, but when adults started using the font on legal documents and gravestones, the public directed its outrage at the typeface rather than at the people misusing it.
Because the iframe is germane mostly to web designers and developers, the story of its undeserved infamy will take a bit more to unpack, but we feel it’s worth telling. Exago uses iframes to embed into host applications, and it’s not uncommon for us to get questions about this practice during product demos. Finding the right BI solution is hard enough without misinformation thrown in the mix, so we’re going to address those iframe myths here.
What is an iFrame?
An iframe or “inline frame” is an HTML element that allows you to embed one document or page in another. iFrame code remains distinct from that of the host page, so its text will not, for example, adopt the host page’s font upon embedding. Interacting with a link or object within an iframe also does not affect the host page. Perhaps you’ve experienced this while reading articles with embedded videos linking to other videos. No matter how many links you click on, you’ll still be in the middle of your original article on gardening, though at this point you may be watching a completely unrelated video about migratory bird patterns or something. That’s because you’re interacting with embedded content! Chances are good you use iframes all the time without knowing it.
Now, it’s important not to confuse iframes with frames, also known as framesets. Framesets have been unfashionable for a long time now and were officially deprecated in 2014 with the initial release of HTML 5, though most browsers still support them. Framesets are used to place documents alongside each other in the same browser window such that no one document takes priority over any other. This can cause a whole host of issues, and it’s possible that some users who denounce iframes are in fact recalling frameset behavior.
Why Do iFrames Get a Bad Reputation?
Both framesets and iframes were released as part of HTML 4 in 1997, back when we used AOL and were just getting used to unusual fonts like Comic Sans, which had come out only three years earlier. It was a time of exploration and experimentation, so of course we made mistakes. These days, framesets are rarely encountered in the wild, and iframes quietly go about their cross-domain business without drawing attention; but our aversion lives on.
Below is a list of common misconceptions concerning iframes. We’ll take time to address each one generally and also discuss how it affects embedded BI like Exago in particular.
1. iFrames are bad for SEO.
Search engines use programs called crawlers (or “spiders”) to comb through search results for identifying information, and they completely ignore iframes. To them, iframes are other pages that just happen to be making a guest appearance on the host page; they don’t count as part of the host page’s content. So, the only way iframes can be bad for SEO is if your host page has no content of its own and is instead just a container for an iframe, in which case crawlers will have a hard time ranking its relevance to a search. This, however, would constitute a failure in implementing iframes rather than a failure of the element itself. As a general rule, you can avoid this one pitfall by making sure your host page at least describes the content in the iframe.
Of course, web applications are generally password protected, so SEO isn’t a priority in the embedded BI world.
2. iFrames make it hard to share links and store bookmarks.
While the URL of the embedded page isn’t as easy to snag as the host page’s URL, it’s not too hard to acquire. In both Chrome and Firefox, simply right-clicking on the iframe content will give you the option to “View Page Source.” Selecting that option will open a new tab showing the host page’s HTML, and a quick search for <iframe> brings you to the source URL. It’s not terribly efficient, but it will do in a pinch.
Once more, this concern doesn’t really apply to web-based BI. Exago uses folders instead of bookmarks for keeping track of reports, and access to those reports is managed on the backend.
3. iFrames complicate debugging.
Because BI applications are inherently complicated, they usually come with debugging tools built in, not to mention technical support. At Exago, if a client is having difficulties with anything related to reporting, we help them get to the root of the problem.
4. iFrames fail to improve performance.
In Exago, we use both iframes and AJAX. The iframe is how we embed into the host software application, and AJAX is how we keep the main menu and folder tree accessible at all times, even while the rest of the frame is transitioning from one wizard tab to another. (So you might be wondering, if AJAX is so seamless, why not just use it to do the embedding too? Don’t worry, we’ll be getting to that shortly.)
5. iFrames cause browser errors.
This is also likely a relic from Web 1.0 days. Back in the mid-90s, browsers were still working out the kinks in handling framesets, so there were a lot of disturbances. The iframe, by virtue of its subordination to the host page, was in part responsible for helping alleviate these kinds of browser problems. Nevertheless, people confused iframes with framesets and have since associated iframes with broken browsers. Today, iframes are old news from a coding perspective, and most browsers support them, though they may differ slightly in their methods.
6. iFrames have bad UX.
Once again, the crime here is in execution. Let us be reminded that “Comic sans doesn’t disappoint people; people disappoint people,” and the same holds true for iframes. In the hands of the unskilled, iframes can indeed be irritating to interact with. One byproduct of the poorly executed iframe is the dreaded double-scrollbar.
There are, fortunately, a number of ways around this unsightliness. There are also ways to avoid generating a seemingly blank iframe when the user links from the bottom of a long page to a short page, another faux pas committed by rookie web developers. In essence, any early iframe UX problems have since been solved.\
7. iFrames are unresponsive to resizing.
Nope, that one’s been solved too. But yes, it’s very frustrating when developers don’t adjust their CSS to enable iframe fluidity. Our UI designer is assiduous about accommodating screen/window size, so we’ve got that covered.
8. You can’t manipulate the content of an iframe.
This one is actually true! Unless the iframe content belongs to the same domain as the host page or another domain you also control, that content is “untouchable.”
With embedded BI, however, you control both the host frame (your proprietary software) and the iframe content (the BI platform). Exago gives its clients full access to the API, complete control over CSS and language files, and the ability to add extensions to the running state. In this case, the iframe acts as a partition between your code and Exago’s code, minimizing the risk of contamination, which brings me to my next point.
8. iFrames pose a security threat.
There are indeed loopholes that can be exploited if the iframe content shares a domain with the host page, but if these frames source different domains, neither is able to access the other’s code or DOM without express consent. DOM stands for Document Object Model—think of it as the page’s central nervous system. The reason pages from separate domains cannot access each other’s DOMs by default is because of something called the same-origin security policy, which exists to keep disparate DOMs safe from one another. Safely opening up communication between domains is possible using Cross-Origin Resource Sharing (CORS), but this requires extra setup.
In sum, cross-domain iframes provide an additional layer of security and same-origin iframes aren’t any less secure than eschewing iframes altogether. Because you’ll have full control over your BI software, both same-origin and cross-domain iframes are safe options; our clients use both!
8. There are better alternatives to iframes.
iFrames really are the best at doing what they do. Though a client-side framework like AJAX could replace the iframe, doing so would sidestep the same-origin policy, add backend complexity, and offer little or no differentiation in terms of experience. If we can give clients the option of having just a little more security with cross-domain iframes, we’ll do it. Our end users build rockets and do brain surgery, so stakes are high.
If you have an iframe concern that we failed to address here, feel free to leave us a comment! Otherwise, we hope you can forgive both Comic Sans and the iframe for their users’ trespasses.