Corey InnisCorey Innis
Javascript Snacks, Nibble #1: RTE/WYSIWYG is Built in to your Browser
edit Posted by Corey Innis on Wednesday May 20, 2009 at 01:52AM

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.

Ingredients

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();

Preparation

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 submission.

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

Comments

  1. gabriel gabriel on May 20, 2009 at 12:47PM

    Thanks for the tasty snack. I've shared it with others: http://queri.ac/commands/pedit

  2. Tom Ward Tom Ward on May 20, 2009 at 12:57PM

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

  3. linoj linoj on May 20, 2009 at 04:28PM

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

  4. Alex Chaffee Alex Chaffee on May 20, 2009 at 05:55PM

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

    WANT!!!

  5. Corey Innis Corey Innis on May 21, 2009 at 01:49PM

    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.

  6. Corey Innis Corey Innis on May 22, 2009 at 02:44AM

    Ready to get your groove on? http://github.com/coreyti/syncopate

  7. Evgeny Evgeny on May 31, 2009 at 06:35PM

    Wooowoo! :)

    Cool stuff

  8. Louis St-Amour Louis St-Amour on July 01, 2009 at 11:17PM

    What I'm looking for, and can't find anywhere is simple:

    The ability to bold, underline, italicize, and apply my own custom CSS styles (ideally with live preview, but that's tough to get right), remove all styles from selected text, and most importantly: image and link abilities like Gmail. To me, Gmail is the model to emulate, but customize it to fit your site instead of a generic email message.

    Why has no one else, for instance, offered Gmail-style link abilities through a tooltip that automatically appears below a link when your cursor is inside. In that tooltip, you see the full URL you've linked to, which is clickable so you can visit it in a new window, along with a button to Edit and another to Remove. Simple.

    Images are trickier, like files, as you will want to style them or treat them differently, sometimes, but not always. For instance, I might want a default behavior to be for an image to be inserted as a left float at where the cursor drags the image. (Or where the cursor is when I click an image button to upload or select an image). Having said that, it's all styling, pretty much, so I suppose the only interesting image functionality, is like links, the live preview, the ability to pick a new image, and (though this depends on the browser I can imagine) resizing the image.

    While I would then want to add my own things to it further, such as common blocks for formatting, etc., all I really care about are that I can apply styles, remove styles, add links, edit them with a tooltip, and remove them.

    I guess what I'm saying is why hasn't anyone copied Gmail yet? It's been at least 2 years that they've been doing this, has no one noticed? I know people who literally use Gmail as an HTML editor, and copy and paste the HTML from there into whatever CMS they use. (I actually used the same technique with some Word documents, stripping formatting with Gmail and reapplying some of it, then copying the resulting email.)

    I'll now take a look at the github you mentioned, Corey, as I'm hoping you've done something cool with your link handling. So far, most posts on contentEditable haven't been as concise as yours, and I'm really hoping that styles, links, images and files aren't too much to ask for. Of course, I haven't even started mentioning content filtering server-side. But hey, if Gmail can do it ...

    Here's what I mean (from a Google Images search):

    http://clarkbw.net/blog/wp-content/uploads/2008/07/gmail-links.png

    BTW, while there I saw some other fun posts:

    http://clarkbw.net/blog/2009/05/14/negotiate-with-your-users/

    And the guy works on design for Thunderbird, so the above Gmail image actually has this post for context, where Bryan compares links to attachments, in Facebook, Gmail: http://clarkbw.net/blog/2008/08/21/what-are-attachments/

    Honestly, I think I would take the facebook approach if a site has lots of links, or if I could somehow provide the editor (or even end user?) of the webpage some context - at least for in-site URLs and pages. It would also work amazingly well if linking to photos or something visual, in addition to a textual representation of the URL as in Gmail.

  9. Louis St-Amour Louis St-Amour on July 01, 2009 at 11:22PM

    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.

  10. Louis St-Amour Louis St-Amour on July 01, 2009 at 11:39PM

    I'll have to play with this idea further, but it appears I can answer my own "How to copy Gmail" question above --

    After peeking at the git for syncopate, I like it. Not sure if I'll use it, but if I do, I'll fork it and contribute my changes, I suppose.

    From googling, and without clicking any actual links (yes, often Google result text is all I need), I suspect I can use the "createlink" command to create the link, and then the link that is created -- or what is under the cursor -- is accessible via parentElement(). I can then imagine a quick absolute-positioned tooltip being created with the parentElement's href as a clickable link, an Edit button to pull up another editor/modal div, and a Remove button to well, replace the A element with its inner text.

    One small other annoyance: You would have to watch for keystroke presses, to see if the cursor is inside a link (via parentElement) and when the cursor has then left the link. I'm not sure how it interacts if the cursor is on the edge of a link. Based on past Gmail (annoyed) experiences, if at the start, it doesn't link (argh, sometimes) and if at the end, it will continue a link (double-argh, unless I'm actually editing a link).

    To be honest, I wish there was a way to set a border around a link's text, and visibly move the cursor from inside the border to outside of it, or vice versa, but I doubt that's easy or intuitive with current tech. I could be (and knowing HTML, likely am) wrong, and would love to be proven so. ;-)

  11. Louis St-Amour Louis St-Amour on July 02, 2009 at 12:09AM

    Wow, I'm so sorry for replying so many times! ;-)

    I tried adding the createlink command, but it didn't seem to do anything in my browser (Safari 4), despite working in other editors.

    But as I continue on this quest, I'm noticing that in addition to the quirksmode chart of contentEditable compatibility (and tester), a quick google search of contentEditable createlink parentElement revealed part 2 of an Opera article:

    http://dev.opera.com/articles/view/rich-html-editing-in-the-browser-part-2/

    And lo and behold, if everything from the link heading on down isn't applicable to what I'd like to do. (But again, note they stick to simple popup boxes rather than doing any more fancy UI work.)

    I particularly liked Opera's parts under A custom command, and a part of me wonders why that isn't the default way of working with this? I mean, if we already know how to insert links and so on with rich DOM tools, why use strange commands like "createlink"? ;-) I'm curious if undo breaks though ...

    It's neat to think then that if you use the DOM route, you can easily pinpoint the cursor in browsers that support ranges, and for IE, you insert a marker element with a unique ID and can then modify from there. Of course, I wonder if I can capture (in IE) the selected text -- perhaps I can't replace createlink in IE, not that I care much about it, really.

    [To correct myself, it appears from MSDN docs and the code sample Opera provides, that you can get the currently selected text, but there's no way to connect that selection to the DOM, which was the problem the Opera article then works around. So yes, it would be possible to use pure DOM methods, which would mean more consistent HTML output, at least from a web design perspective.]

    BTW, this comment system needs a preview and an edit button. ;-)