Am I crazy? (How) should I create a jQuery content editor?

Question

Ok, so I created a CMS mainly aimed at Primary Schools. It's getting fairly popular in New Zealand but the one thing I hate with a passion is the largely bad quality of in browser WYSIWYG editors. I've been using KTML (made by InterAKT which was purchased by Adobe a few years ago). In my opinion this editor does a lot of great things (image editing/management, thumbnailing and pretty good content editing). Unfortunately time has had its nasty way with this product and new browsers are beginning to break features and generally degrade the performance of this tool. It's also quite scary basing my livelihood on a defunct product!

I've been hunting, in fact I regularly hunt around to see if anything has changed in the WYSIWYG arena. The closest thing I've seen that excites me is the WYSIHAT framework, but they've decided to ignore a pretty relevant editing paradigm which I'm going to outline below. This is the idea for my proposed editor, and I don't know of any existing products that can do this properly:

Right, so the traditional model for editing let's say a Page in a CMS is to log into a 'back end' and click edit on the page. This will then load another screen with the editor in it and perhaps a few other fields. More advanced CMS's will maybe have several editing boxes that are for different portions of the page. Anyway, the big problem with this way of doing things is that the user is editing a document outside of the final context it will appear in. In the simplest terms, this means the page template. Many things can be wrong, e.g. the with of the editing area might be different to the width of the actual template area. The height is nearly always fixed because existing editors always seem to use IFRAMES for backward compatibility. And there are plenty of other beefs which I'm sure you're quite aware of if you're in this development area.

Here's my editor utopia:

You click 'Edit Page': The actual page (with its actual template) displays. Portions of the page have been marked as editable via a class name. You click on one of these areas (in my case it'd just be the big 'body' area in the middle of the template) and a editing bar drops down from the top of the screen with all your standard controls (bold, italic, insert image etc...). Iframes are never used, instead we rely on setting contentEditable to true on the DIV's in question. Firefox 2 and IE6 can go away, let's move on. You can edit the page knowing exactly how it will look when you save it. Because all the styles for this template are loaded, your headings will look correct, everything will be just dandy. Is this such a radical concept? Why are we still content with TinyMCE and that other editor that is too embarrassing to use because it sounds like a swear word!?

Let's face the facts:

I'm a JavaScript novice. I did once play around in this area using the Javascript Anthology from SitePoint as a guide. It was quite a cool learning experience, but they of course used the IFRAME to make their lives easier. I tried to go a different route and just use contentEditable and even tried to sidestep the native content editing routines (execCommand) and instead wrote my own. They kind of worked but there were always issues.

Now we have jQuery, and a few libraries that abstract things like IE's lack of Range support. I'm wondering, am I crazy, or is it actually a good idea to try and build an editor around this editing paradigm using jQuery and relevant plugins to make the job easier?

My actual questions:

• Where would you start?
• What plugins do you know of that would help the most?
• Is it worth it, or is there a magical project that already exists that I should join in on?
• What are the biggest hurdles to overcome in a project like this?
• Am I crazy?

I hope this question has been posted on the right board. I figured it is a technical question as I'm wanting to know specific hurdles and pitfalls to watch out for and also if it is technically feasible with todays technology.

Looking forward to hearing peoples thoughts and opinions.

UPDATE

I've decided I will have a go at this and will start a github project for it when I have something cool to look at. From there I'd be totally happy for any help that people have to offer. It'll be open source of course :)

UPDATE 2

I've made the project and outlined the objectives. Let me know if you want to join the project group as a contributor, but I'll get the basics up first so there's something to start with.

Here's the link: http://github.com/brendon/SpikeEdit

Update 3

Wow! I've found this project. What a cool idea! I'm getting in touch with him to see if he ever got anywhere with it:

http://www.fluffy.co.uk/stediting

Update 4

Ok, I got reasonably far. The biggest problems (like everyone always knows) is how to keep the code being generated in a reasonable state of affairs. WYSIHAT seems to have take on board the whole non-IFRAME thing, so I'm holding off to see how far that gets. They take the approach of just cleaning up the code at the end of the editing cycle. I think it should be cleaned on the fly otherwise you can edit yourself into a quagmire (I've done it a few times). When I have time I'll investigate some sort of homogenisation engine that could be plugged in to make the editing process behave as similarly as possible in all modern browsers.

Answer 1

If I'm understanding correctly, you pretty much want dynamically editable fields (see: facebook, other ajaxy-web2.0 sites). So, that would mean you'd just set the class of the (or whatever) to the appropriate name and have jquery transform it into a textfield/textarea onClick. I think jquery does something like this with one of their plugins. Anyway, then you could have per-field updates (in case you didn't want to edit the entire page, or have to update the whole page/entity to edit one field).
Of course, this would take a small bit of ajax and some backend work to tie it together, but that's pretty trivial imho.

Answer 2

Have you tried uEditor? It's a solid and simple Jquery solution that turns textarea's into WYSIWYG editors

//Grab the content of the editable area then replace it with a textarea like so...

var editableContent = $(selector).html();
$(selector).after("<textarea>" + editableContent + "</textarea>")

// add attributes to text area as desired

// kill the original area:

$(selector).remove();

// call uEditor

$(textareaSelector).uEditor({options});

You'd obviously then add options and event handlers to uEditor.

Just a thought. Rob

Answer 3

This may help.

Joe Armstrong had pretty much the same idea as you a little while ago and spent a week or so playing around with ContentEditable paired with CouchDB for persistance. He didn't end up with a highly polished editor, but it's a good starting point for rolling your own (if that's what you want to do). It seems like it would be fairly simple to take what's there and get it into a solid in-context editor.

As a note, I agree with your notion that editing interfaces should be as close in context and layout to the artifact they're editing as possible. Let me know if you end up rolling your own; I'd be interested in contributing to a project like this.

Before you go out and make an editor though, it might pay to check out what your users are actually doing. In corporate IT, nine times out of ten what you'll see is people putting their pages together in Word or somesuch, then pasting the results into whatever "editor" you have. I don't think that would work too well with the ContentEditable method. Incidentally, this is why we still use TinyMCE; it has a half-way decent "Paste from Word" button. You're aiming the tool at primary schools rather than a corporate environment, so things may be different there.

Answer 4

JQuery does have a lot of WYSIWYG editors, but to be honest I've been disappointed with most of them. What you suggest sounds very useful. Here's how I'd do it:

First an object only gets key events when it has the focus. The best way to get around this is to catch key events at the page level. Then append the correct character to the div that's currently being edited. That would handle basic typing in any div which would probably be the first thing you'd want to tackle.

Next you'd want a tool bar which should probably be pulled out of the page by setting the display to fixed. You'd need some logic to insert spans and such to handle stylizing the text.

Of course, if you build all this yourself you'd need to build everything - even the blinking cursor showing where your typed characters go. Selecting text, inserting the cursor in the middle of text, copy and paste; you'd pretty much have to build all the stuff we're use to getting from scratch. The other option is to use some sort of text box, but as I understand it, you'd like to avoid that.

So anyway, my final verdict is that its possible but it would still be a lot of work. It seems like there's a good deal of interest in it though so you could probably get some help.

Answer 5

Trying to create another WYSIWYG editor is a waste of efforts. You'll have to replicate all the code already available in other editors to handle the special issues that are needed to generate correct HTML, make it easy to edit elements, manage correctly the keyboard...

It's better to use an existing one that it's under development and first try to use it as is, make sure that it handles your code and generates what you want, then learn how to adjust its width to match the container, automatically adjust its height to its contents, put the toolbar in an external div, and you'll have what you want. If you want to really get rid of iFrame, then go ahead and send them patches to do so if they don't already provide that ability, but that will be far easier than creating everything from scratch.

And I can assure you that there are lots of people that have been using this kind of setup for several years without the need to care about what's the internal element used for editing, including making any part of a web page editable by a trigger like a context menu, double click or floating button. They just focus on the CMS and let the details about the editor to a dedicated team.

Answer 6

Ok, wow! These guys are doing exactly what I was thinking of:

http://aloha-editor.com/

I don't like their toolbar much but they're actual functionality looks great! I'll be keeping an eye on their progress :)