Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Javascript Snacks, Nibble #1: RTE/WYSIWYG is Built in to your Browser

The Label

“Tasty! No Trans-Fats.”

I’ve now worked with a number clients who have a taste for a “rich text” editor
experience. Each time, the team initially looked in to using an
off-the-shelf package, e.g.:

Each of these client projects had fairly basic needs.
Pretty much everyone wants “bold”, “italic”, “underline”. Throw in bulleted
and numbered lists and perhaps a few other trinkets and you’ve pretty much
covered the use cases.

It turns out that the existing packages are generally tricky to integrate and
modify or configure per your particular needs. This makes sense. A full-blown
Javascript RTE package needs to have capabilities far in excess of anything
a given project requires, simply in order to meet every project’s
requirements. You end up with a massive library that is not trivially
integrated into your site. What to do some TDD/BDD on the RTE interaction
with your page? Good luck.

So, I’ve generally suggested that we roll our own.

I know, crazy. Why write something new and custom when so many others have
already solved all of the issues with, for example, cursor movement and text
editing and command handling (e.g., making the text “bold”) and image
placement, and…?

Well, it turns out that all of that
behavior is already built in to the browser. Yes, my browser, your browser.
Pretty much every browser you need to care about1.
On top of that, the basics are extremely simple.

To many, this may not be news at all. The basic capability has been around since MSIE 5.5 was released in 2000. On the other hand, I’ve worked with a number of very smart and seasoned web developers who were unfamiliar with the extent to which it is the browser, rather than the libraries, that has taken care of the hard parts.


What you’ll need to make this work2:

// enable editing:
document.contentEditable = true;
document.designMode      = 'on';

// make something bold:
document.execCommand('bold', false, []);

It’s pretty much as simple as that. Give it a try: paste the following
snippet into your browser’s address bar, hit enter, and edit text or resize
images on this page to your tummy’s delight.

javascript: function enable_DM() { document.contentEditable = true; document.designMode = 'on'; }; enable_DM();


So, with those ingredients we can make quite a mess of the page we’re visiting,
but we’ve hardly created a delicious RTE. To go the next step, we need a way
grab the HTML representation of our edited content to send with a form

The basic idea here, which is what every editor out there employs,
is to embed an <iframe />, the document of which is editable, and when
appropriate copy the HTML of that document to a (likely hidden) textarea within
your form.

Why an iframe? There are two important reasons:

  1. You probably want to protect the look and behavior of your edited document
    from the styles and scripts of the rest of your site.
  2. Until version 3, Firefox only supported designMode, which is applicable
    to the document, but not to an element within your page.

There are slight browser differences that will come in to play, e.g. MSIE’s
IFrameElement.document property versus Firefox’s (and the W3C standard)
IFrameElement.contentDocument. As long as your editor remains fairly simple
these intricacies will cause very little trouble.

I’ll leave it to you to hook things up to your liking, but will toss in this
morsel: On a current project, we’re using a home-baked RTE which, from 100
very-nicely-formatted lines of Javascript (not counting the supporting
jQuery and Disco
libraries), is providing…

  • DOM building of the iframe and command toolbar (<ul /> with “buttons”), etc.
  • Document editability
  • Registration and handling of 8 commands (e.g., “bold”, “italic”, “indent”)
  • Content transfer to-and-from an associated textarea
  • Additional helpers (e.g., get the currently-selected text as HTML)

Tasting Notes

  • 1 My apologies to visitors using a
    specialized browser for accessibility.
  • 2 Setting document.designMode
    should be enough, but there are reports of discrepancies in MSIE’s handling
    of the two.

Shopping List

  • Thanks for the tasty snack. I’ve shared it with others:

  • This is marvellous. Where has this information been hiding all this time?

  • linoj

    All these years, and I never knew about this. A rails / jquery plugin for this would be awesome :)

  • Alex Chaffee

    > On a current project, we’re using a home-baked RTE


  • Corey Innis

    Glad you all found some interest.

    @linoj: Can you clarify what it is you’d want to see in a plug-in. Part of what I’m trying to suggest is, this is simple enough that it may make sense to build things to your project’s specific needs. However…

    @Alex: I’ll get something up on The GitHub today and share it here.

  • Corey Innis

    Ready to get your groove on? [](

  • Wooowoo! :)

    Cool stuff

  • Louis St-Amour

    Speaking of writing HTML, you should also copy Gmail here, and make text that begins with http:// a link automatically. Gmail has some fancy rules to ensure that punctuation isn’t considered part of a link also, I believe. Okay, so simplicity like Google’s is tough, but I still don’t see why more people haven’t adopted it. Does it feel too much like re-inventing the wheel?

    I would suggest something like X-Standard, if it only was free/open source, and a bit more Gmail-ish, without being too generic or hard to customize. For instance, to me, the distinction between large and small fonts or even font-faces, and styles, is something that for most website designers or even commenters, you don’t care about. Colours you might care about, but the best choices could be entered in also as styles or classes to mix and match. No need for extra buttons for that… And while a component like XStandard creates perfect XHTML, it requires installation beforehand, and it’s harder to modify too.

Share This