Hi Jonathan - Thanks for sharing. This seems like a clean and lightweight plugin. Are you planning on converting this into the widget factory and making it themeroller-ready? Any info on your goals and the documentation would be good to see, thought he code is pretty easy to read.

Editors like TinyMCE allow you to specify what stylesheets the iframe should load - this is pretty simple. It also should be easy to add stylesheets and <style> blocks to the iframe automatically by copying the links and styles from the current page into the iframe. This could be the default or a simple options like:

duplicateCurrentPageCSS: true

However, not sharing stylesheets is also a major *advantage* of iframe editors. For example, I use editors inside a backend site-management application. The stylesheets used by the backend app and those required for the content editors are *completely different*, so it would be impossible for me to use an editor that was reliant on the styles in the 'current page'. In fact, the app can edit content from multiple websites, so I can configure the editors to use the stylesheets from the relevant website.

Therefore, while an inline editor has its advantages, it is unsuitable for a wide variety of uses. But an iframe editor can handle both scenarios, so if the goal is to address all needs and provide accurate WYSIWYG, it seems that an iframe editor is the best option.

FYI: TinyMCE supports a contenteditable mode where it runs without an iframe and without a toolbar if you want to. This is scheduled to be used in the next generation of the Plone CMS user interface.

The definition of 'rich text' is that it's formatted, so an editor is non-function without a toolbar (or context menu). So this *core functionality* should work out-of-the-box and not require each user to reinvent the wheel just to get a basic toolbar. The Richtext widget should *integrate* other widgets as needed to make things simple.

Creating a *fully functional richtext editor* should be as easy as:

$('#myTextarea').richtext(); // includes basic toolbar
OR
$('#myTextarea').richtext({ showToolbars: false });

Configuring toolbars should not require 50 lines of code. The TinyMCE widget is a good example of a simple, intuitive config...

$('#myTextarea').richtext({
toolbarLocation: "top"
, toolbarAlign: "left"
, toolbarButtons1: "fullscreen,|,preview,print,|,iespell,|,undo,redo,|,cut,copy,paste,pastetext,|,code,cleanup"
, toolbarButtons2: "styleselect,|,formatselect,|,bold,italic,underline,|,bullist,numlist,|,removeformat"
, toolbarButtons3: "template,|,image,|,hr,nonbreaking,|,link,unlink,anchor,|,sub,sup,|,charmap,emotions,|,visualaid,visualchars"
});

In 5 lines, this defines a very rich set of toolbars. The widget handles generating and binding the controls, so even a newbie can customize the widget in a few minutes. These options could handle 95% of cases.

The Richtext widget should handle integration with other widgets so users don't have to. Everything - toolbars, context-menus, resizable, etc. - should have reasonable defaults, as it is with all other UI widgets. Customization should be an option, not a requirement. Basic functionality should require no options as all.

I see the logic for a separate richtextToolbar widget so toolbars could be generated where and when needed, but this does NOT require a stand-alone widget. A toolbar method is simpler and more consistent with other UI widgets, eg:

$('#myTextarea').richtext('toolbar', { name: 'pageToolbar', wrapper: '#header', buttons: 'bold,italic,underline' });

This automatically binds the toolbar to the editor instance and allows toolbars to be created on the fly. It also makes it easy to include this config as part of the editor options... Since multiple toolbars/rows is common for editors, this example uses an array of the same options used by the toolbar method...

$('#myTextarea').richtext({
toolbars: [
{ // same options as above...
name: 'pageToolbar'
, location: '#header' // wrapper selector
, align: 'center'
, buttons: 'bold,italic,underline'
}
, {
location: 'top' // keyword [top|left|right|bottom]
, align: 'left'
, buttons: 'bold,italic,underline'
}
, {
location: 'top' // 2nd row
, align: 'left'
, buttons: 'bold,italic,underline'
}
// top/left-align is default anyway...
, { buttons: 'bold,italic,underline' }
]
});

The options per-toolbar could include options intended to pass-through to the UI Toolbar widget. It is easily to extended this over time. For example, to add functionality to remove or disable a toolbar using the API...

$('#myTextarea').richtext('toolbar', { name: 'pageToolbar', action: 'remove' });
$('#myTextarea').richtext('toolbar', { name: 'pageToolbar', action: 'disable' });

My 2-cents.