Replicating some of the functionality in SCEditor

Question

In my current application I have created a custom BBCode editor - I use a number of BBCode extensions and have other integration requirements that make it imperative that I use my own editor rahter than an off-the-shelf one.

Creating this, ensuring that the generated BBCode is always valid, gets translated to good HTML etc was a great deal of work but I am very pleased with the results. However... as things stand I am obliging the end user to view and edit BBCode. It would be nicer to have WYSIWYG. I note that SCEditor has a WYSIWYG interface. Looking under the covers with Chrome's excellent debugger I noted the following

• The original text area is hidden
• A div containing an iframe is inserted
• The document in the iframe contains a contenteditable div and a hidden textarea control

I could continue my explorations and figure out just how all of this is done. However, I am hoping that someone here might be able to give me a few pointers on what is required here. I imagine that the entered BBCode is somehow "diverted" into the hidden textarea, gets parsed to HTML on the fly and the results are shown in the content-editable div or something along those lines? There would also be the issue of correctly dealing with mouse clicks and selections.

Answer 1

SCEditor works by having a BBCode parser and a DOM to BBCode converter (it's a bit ugly at the moment).

Initially the editor converts the BBCode from the textarea into HTML via the BBCode parser and puts that inside the contentEditable element of the iframe. The user can then edit the contents of the contentEditable element just like any other HTML WYSIWYG editor.

When the form is submitted or the user wants to view the BBCode source, the DOM is then translated back into BBCode via the converter. Translating from DOM to BBCode can be done accurately since it's essentially what BBCode is parsed into anyway.

So for example, for bold you can check if the node has a style.fontWeight of bold or if it is a <strong> or <b> tag. For other elements like links, you just use the href attribute and wrap the contents inside a [url] tag.

Finally the resulting BBCode is parsed a second time by the BBCode parser and outputted with whatever BBCode output options are set. There isn't really a standard for BBCode so things like newlines after block-level elements should be configurable.

Essentially what SCEditor does is:

• BBCode -> DOM
• Edit via contentEditable
• DOM -> BBCode

---

What I've learned from creating SCEditor is that unless you want to spend years perfecting it, don't write a WYSIWYG editor with contentEditable, just use/build on someone else's. There's an answer on another post by a CKEditor dev saying pretty much the same thing.

If you do want to make your own WYSIWYG editor, using Rangy for the dealing with browser selections should make things a lot easier. The native browser selection APIs are (or at least were) very buggy! Not only that, IE < 9 uses a completely non-standard method of accessing selections. Rangy provides a common API that works with IE's non-standard approach as well as working around browser bugs.