Editors and iframes

Jason Chen
4 min readNov 2, 2014

--

Originally published at www.jasonchen.me on November 2, 2014

Before building Quill, I surveyed the landscape of rich text editors. A common characteristic of all the powerful and widely used ones operated within an iframe–but the reason for this was more of a mystery. It’s hard to go against the grain when literally all the popular editors were aligned on iframes, but at the same time most of them made this configurable. What I hoped to find was a differentiator that necessitated the use of iframes.

I originally ended up deciding to go with iframes for Quill as well. But after experiencing firsthand the consequences of this choice and being able to speak directly with other editor authors, I now believe isolating Quill in an iframe is a mistake. This post is what I wished was available when I started, and a summary of all the knowledge I have gathered on the topic.

Protection

The most discussed benefit of iframes is separation from other styles and scripts on the web page. The benefit is bidirectional, but the challenging side is external scripts and styles affecting the editor. For one, it’s an unknown quantity. But also when conflicts do arise, users largely blame the editor. One early user of Quill had a script that literally monitored for and removed every <br> tag on the page.

The problem with this benefit is it only reduces the likelihood of conflict. If users wanted to mess with the editor, they still can and iframes will offer no protection. So we can only consider unintentional interference. This is a diminishing benefit as front end debugging tools become more powerful and library authors more responsible and conscious of their footprint (probably from natural selection). To my knowledge there is no widely used library that interferes with the operations of Quill.

There are tangible drawbacks to the “protection” afforded by iframes however. Browser specific behaviors that are expected and desired will be prevented. Here are a few examples:

  • The editor might be used as a rich form field and tabbing into it will not work without custom logic.
  • The editor also cannot autogrow with the content since iframes do not autogrow. This limitation also lacks a good workaround.
  • Analytics libraries are commonplace today and an iframe is essentially an events black hole.
  • The back button controls history of the page and not the iframe, so hitting the back button after clicking on a hash link inside an iframed editor linked to another section of the editor will not work as expected.

The cursor position is also saved by default per document. This is useful for example when the user clicks on a bold button outside the editor, the browser will restore the cursor over the right position when the editor gains focus again. This is not the case in IE however, so saving and restoring the cursor needs to be handled in a cross browser editor anyways.

Control

Another benefit of an editor being isolated in an iframe is that one can choose and control all aspects of the document without fear of adversely affecting other parts of the web page. Practically, this means controlling the doctype, the contents of <head>, and a feature called designMode.

Doctypes have their own fun filled history but today there is little fragmentation and misuse. Quirks mode has been shamed out of existence and an astounding 92.29 percent of the top 10,000 sites use the standard declaration. Even the next several percentages of popular declarations have no adverse affects on Quill. Quirks mode will most likely break an editor but its usage is now more of a user problem than a technological one.

The only legitimate reason I can think of for an editor to modify the <head> is to add <style> tags. This should not adversely affect the rest of the page if properly namespaced. Some bookkeeping does need to be done when supporting multiple instances of an editor but given caching it is not clear there are noticeable effects of having duplicate <style> tags other than sloppiness.

Many rich text editors, including Quill, depend on contenteditable, the browser technology that makes the DOM directly editable. Born from the same loving womb of IE 5.5 was designMode, which is essentially contenteditable except it is applied to an entire document as opposed to a single DOM element. There was a period of time where a browser supported one but not the other (most notably Firefox 2 supported designMode but not contenteditable), and even when both were available, one implementation was often less buggy than the other.

Moving Forward

For the next version of Quill, iframes will be removed altogether and the benefits are already being felt even before release. A much simplified codebase no longer needing to manage an iframe and track multiple window and document objects has already enabled a 4k savings of minified code.

Only the original authors of the respective editors can answer definitively as to why they chose to utilize iframes but I believe the reason is largely historical. The prevalence of quirksmode and lack of availability and stability of contenteditable left little choice but to use an iframe from 2000 to perhaps as late as 2010. But today this is no longer the case and there remains little reason to continue this artifact of history.

Thanks to Byron Milligan and Steven Wu for reviewing this post and David Greenspan and Mime Čuvalo for answering my iframe questions.

--

--

Jason Chen
Jason Chen

Written by Jason Chen

Co-founder of @slab, BDFL of @quilljs

Responses (9)