IFrame must die!

Guillaume Montard photo Comment

Yes IFrame must die, that’s it! Seriously does anyone still use IFrame? Yes and I’m not alone! Do I have any choice, no! Why we need to kill this technology and find a good replacement, let’s find out..

Why use IFrame?

IFrame was released with HTML 4.01 and introduced in 1997 by… Microsoft Internet Explorer! (Remember this for the next paragraph). This is an evolution of the basic « frame » object which purpose was simple, split web page elements in the form of windows. IFrame was built in order to display a target element, in simple words a way to add content from website A to website B… hum!?

Today we should use API to accomplish this behavior, in 1997 API was not so popular! The problem is that API and IFrame are not the same and even if we can replace it most of the time, it’s not always true.

Who still use IFrame today?

Maybe you think IFrame is long dead and nobody use it anymore. Wrong wrong wrong!

IFrame is all over you web pages nowadays and maybe even more than before. For example, when you see a Facebook or Twitter share button in fact it’s an IFrame. As a developer, most of the time we give you a simple line of Javascript that is responsible to render and load an IFrame and inside it the content (the share buttons).

We could do that with an API call, but it would require far more complexity on the webmaster part. Think about cross-domain restriction and all those nifty things we love about the Web. An other example is the Youtube player, when embedded into a web page it uses IFrame.

At my company we have a special use case, more specific, but very interesting of the problems surrounding IFrame. To summarize in order to integrate our solution into our customers LMS (like an extranet dedicated to e-learning) through SCORM package we include our content inside those SCORM using an IFrame. This means our entire SaaS platform is embedded inside an IFrame taking full width and height. The only other option would be to open an other new window (the SCORM already open one) which goes against good UX principle. We’d really love to have an other solution, but there is not (any idea?).

IFrame support is poor… Thanks to IE!

As mentioned above my use case is very special and in fact it showed us all the limitation and the poor support of IFrame across browser vendors. IFrame was crafted by Microsoft, we could assume their support of this technology is good, sadly it’s not.

One crazy example is with sprites. On our platform we manage all our images using nice sprites which works quite well. Without any explanation, IE9 doesn’t support our CSS using sprite when embedded inside an IFrame. The only solution for us is to disable those sprites on IE9 when our platform is loaded inside an IFrame. Why? I honestly don’t know and I’m not sure MS knows either.

An other example is with our video player. We use VideoJS in combination of Flowplayer to manage HTML5 and Flash versions depending on the browser used. In Fact we do a simple fallback to HTML5 if the user doesn’t have a proper flash version (I hope one day to switch this fallback order!). IE, from version 7 to 11, throw a weird JS exception over VideoJS when running inside an IFrame.

At the end it’s possible to handle those problems, but it’s hard to predict the behaviors. Now comes the hard part, session (~cookies) management.

What is a Third-Party cookie? Basically a cookie that is set by a web site you’re not « intentionally » visiting. The problem lies in « intentionally ». When you use web site A that embed an IFrame from Website B, your browser consider web site B as a 3rd party. Where does this lead us?

In order to be more aggressive against tracking and advertising, browser vendors started to ban those cookies, meaning they also banned our session variable. Back to my example, our IFrame perform some kind of SSO authentication to log the user, so not having a persistent session variable means losing the user identity.

For Internet Explorer to accept those cookies it’s relatively easy, you just need to use the P3P headers. If you are using Ruby On Rails I’ll advise you to use this simple gem.

Safari is today the most restrictive by not allowing any third party cookies IF you haven’t previously visited the website sending you this cookie through an IFrame. The only to resolve this for us was to brefiely open a window on our domain, set a simple session, then close it and proceed to the loading of the IFrame. It’s not pretty, but not that much intrusive considering there is no alternative.

Firefox and Google Chrome don’t require any bypass of hack, at least for the moment. Last year Firefox proposed to ban those Third-Party cookies the same way Safari does. At the last minute this feature was removed of the release and hasn’t yet been added. There is no words from Mozilla why it wasn’t released or when it will be.

So…

Those Third-Party cookies restrictions are good for you as a user in order to prevent anyone to track you everywhere, but use case like ours suffer from it. Even without doing things too tricky as we do, the support for IFrame is not pretty poor, it’s like a **degraded web experience.

Either we kill those IFrame or we finally decide to build something better into HTML, what do you think?