Perhaps one of the weakest areas in editors today is the file upload / requester. They are not making them generic enough to be used all over. This might be a great area to hook into a data library for portability of technology. (It is more accessible to learn a thing once and reuse it over and over.)

I've created a modified version of rte-light for my current project. Uses an icon-sprite instead of single images for the toolbar and some other stuff I needed. Might be a good starting point.

TinyMCE and the like all have the problem of a massive core. You can just start with a plain editor and select the few features you ned. Instead you always get a massive default selection and some optional plugins.

TinyMCE has a great plugin system, and those provide a JQuery implementation. I would be in favor of supporting that project. (And it's more open source than CKEditor too.) As for the file upload, you need a backend for that and this falls outside the JQuery UI scope. However, I guess the richtext editor could provide all the necessary interfaces and all one could do is simply implement the ncessary scripts for the backend. For exemple, the editor initialization could have options such as :

handlerURL tells what URL will handle all requests (upload, get, list, etc.)
dataFormat a callback to format the data received from the url

Or some other options, but just that covers the basics, I think

Was surprised when I saw the list of editors was missing my own personal choice, TinyMCE --> http://tinymce.moxiecode.com/index.php

Note to self, read comments before you comment... But yeah, like Yanick wrote, since a few versions back Tiny also works as a JQuery plugin that has potential.

The base editor should provide the necessary API to manipulate the inner HTML document, but should not provide all the "basic" functionalities (bold, italic, etc.), but should provide everything as "plugins" (that term should be reviewed to avoid confusion with "JQuery UI plugins" or "JQuery plugins"). The principle of "commands" callback is present on most of the extensible rich text editors. Consequently, the rich text editor should provide it's own "plugin" management system (I will call them "commands" for now on), something similar to the JQuery UI Widget factory. Then, all there would be is to include the Javascript (no need to call a registration method). Such command could be :

$.richTextEditor.command("insertImage", {
_init: function() {
// this.getEditor() could be an automatic function provided by the factory that would return the associated editor for that command instance
// this.options.someOption = someValue; // see below
...
},
...
execute: function([args[, ...]]) {
// var editor = this.getEditor();
...
},
...
});

// optional
$.extend($.richTextEditor.commands.insertImage, {
someOption: someValue,
...
});

Commands could be registered but not initialized in this way. The _init method would be invoked when an editor make use of that command. The execute method would be invoke when using the command within the editor. Using such command could be as easy as:

$('selector').richTextEditor('execute', 'insetImage'); // extra parameters would be directly passed to the command's execute function.

I forgot to mention, commands would then be declared with the instance of rightTextEditor like :

$('selector').rightTextEditor({
commands: ["insertImage", ...],
...
});

To ease the use of default commands, there could be predefined command arrays, such as :

$('selector').rightTextEditor({
commands: $.ui.richTextEditor.basicCommands,
...
});

- basicCommands
- allCommands (comes with all the official provided commands
- etc.

setting this attribute to an empty array, or null would mean no command available, just a rich text editor box to display text. The default could be basicCommands.

Hello everybody!

I've been reading this wiki and using jquery for a while. Also, I work with a media company, with many Content Management Systems and many types of Rich Text Editors. These all have a few common problems:
- lack real cross-browser functionality
- are way too complicated (simple users will use these editors, mainly journalists)
- none have inline editing funcionality (the most ideal rte for a user is one which offers him the possibility to edit the real content) - maybe contenteditable property should be considered
- a rte has to be combined with a media gallery wodget (pictures, videos) - without this, in nowadays webcontent it becomes obsolete from the start

Due to the above reasons, I started writing a inline editor. There is one more feature that I considerred: a ribbon menu (when I started planning it I wasn't familiar with the ribbon plans). I grouped the buttons and the next step would be to organize them on tabs.
I find the ribbon menu very important, because many users are not familiar with the icons (copy, paste, and the rest).

These are the Ideas that I find very important.
I'll be back :)
Edi

Also, instead of of multiple editor instances (when someone needs more than one editor on a page), what if we have only one toolbar? And this can edit any of editable html content.

I would just like to chip in that wymeditor is very sensible editor for use in a template based CMS. By focusing on the meaning of elements, rather than the visual appearance, the output is much better. But it is a matter of the desired use case, of course.

Extending to provide upload functionality is trivial, and could certainly be made excellent with some love from the jqueryui team.