View
 

RichTextEditor

Page history last edited by Yanick 10 months, 1 week ago

 

type: widget

release: 0.0

status: in planning

documentation: url || N/A

demo: url || N/A

 

 


 

1 - Description:

 

A rich text editor provides a WYSIWYG view of HTML markup and usually includes a formatting toolbar, right-click menu with selection tools, spell correction and cleanup functions for content pasted in from other applications (Office code cleanup is especially important).

 

There are a wide range of very robust rich text editors we may want to consider:

http://www.fyneworks.com/jquery/FCKEditor/

http://www.avidansoft.com/dsrte/index.php

http://batiste.dosimple.ch/blog/2007-09-11-1/ (http://code.google.com/p/rte-light/)

http://www.themaninblue.com/experiment/widgEditor/

http://www.wymeditor.org/ (highly recommened by Marc)

http://xstandard.com/ - from their site, is the leading standards-compliant plug-in WYSIWYG editor. Though it is distributed as a plug-in and not a pure JavaScript library there are quite a few interesting articles on their site with regards to HTML standards and Accessibility for rich text editors. Might be a good resource.

 


 

2 - Visual Design:

 

 


 

 

3 - Functional Specifications/Requirements:

 

(Detailed descrition of how the script will be structured: defaults, options, architecture, extensibility, etc.)

 


 

4 - Markup & Style:

 

     4.1 Initial markup examples

 

     (Pre-enhanced HTML markup structure that will be transformed into the final widget. There may be multiple possible HTML markup options per widget: for example, for a slider, radiobuttons, inputs or selects could all be used. )

 

     4.2 Recommended transformed HTML markup

 

     (The HTML markup structure and classes that will be used by the scripts in the enhanced version) 

 

     4.3 Accessibility recommendation

 

    (Detailed recommendations for ARIA, HTML markup, CSS and javascript that will contribute to universal access and full section 508 accessibility for screen readers, mobile devices and any other devices) 

 

     4.4 CSS & Theme

 

The icon set should include all necessary, basic, icons for the available base editor tools :

 

  • bold (.ui-icon-bold), italic (.ui-icon-italic), underline (.ui-icon-underline), strike through (.ui-icon-linethrough)
  • un-ordered lists (.ui-icon-ulist, .ui-icon-olist)
  • alignments, indentation (.ui-icon-alignleft, .ui-icon-aligncenter, .ui-icon-alignright, .ui-icon-indent, .ui-icon-outdent)
  • etc. 

 


 

5 - Latest version of plugin:

 

(Link to the latest version in the jQuery UI trunk here)

 


 

6 - Open issues being discussed

 

(Use this area to place things that we're hashing out like featuresand options we're not sure we should include, questions about how this fits into UI and relates to other widgets and utilities, known problems, whether features should be broken across multiple releases, etc.)

 


 

 

 

 

Comments (25)

Jörn Zaefferer said

at 7:41 am on Mar 9, 2009

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.

Edi said

at 8:28 am on Nov 20, 2009

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.

Jonathan Gotti said

at 6:28 pm on Feb 10, 2010

Hi i share here the work we've done in our company used in production environement for 2 years now.
we are waiting for buttons to be ready to use them as toolbars buttons and then rewrite the plugin to use ui-factory.
At this time it support possibility to plug your own function for some command and the possibility to put some user defined style in a selector ( apply style selector ).
There's no other documentation than the code itself if you want to have a look at it for inspiration or don't know... just to share our work.
here's the demo link:
http://dl.dropbox.com/u/1151318/jqueryRte/demo.html

Todd Parker said

at 10:41 am on Feb 11, 2010

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.

Jonathan Gotti said

at 5:09 pm on Feb 11, 2010

ps: don't hesitate to contact me by mail if you have any question

Jonathan Gotti said

at 5:08 pm on Feb 11, 2010

Hi Todd thanks for the review.
Our goal regarding this plugin is to replace buttons in the toolbar with a unified jquery-ui buttons plugin (that was part of the reason i made work previously on that particular plugin.) so it can be themed with theme roller and so offer a visually well integrated editor. Obviously we also plan to convert it into the ui widget factory, and make some better documentation than the code for it.
The time missing, well established ui-button and ui-toolbar plugins are the only need for us to make it happen.
At this time i don't have any of these (particularly the time) so i can't really work on this but i'll be pleased to answer any questions if you have any, or work on it when time will be available.

regards.

Michael Lang said

at 11:13 pm on Mar 1, 2010

I found another editor recently. The editor has the command plugin pattern support Yanick proposed. http://jhtmlarea.codeplex.com/

I've added my own plugin to add an 'image gallery'. When I click on my custom command it opens another page in a window where the user can pick one or more images to insert. I prefer to have users navigate to virtual images that can be inserted in the document instead of exposing a dialog that navigates to physical files on the server. I let users upload an image to a database or the cloud without exposing the storage mechanism to them. I think it may be beyond the scope for a base jQuery UI plugin to support navigating to images in a specific location. Support for entering an image url may be sufficient in the base plugin.

mokush said

at 1:00 pm on Jun 16, 2010

Hey sorry for the bad links earlier. Since the last post I've moved everything to a new host.
You can see the same demos here:
http://dev.ghinda.net/jquery_ui_rte/

and download
http://dev.ghinda.net/jquery_ui_rte.zip

This is more a concept than an actual usable rte, especialy theme integration, but I'll probably start some serious work on it in the following weeks, most probably using html5 contenteditable.

Yanick said

at 2:37 am on Jun 28, 2010

I tried http://jhtmlarea.codeplex.com/ and liked it's simplicity, so I implemented a widget factory enable richtext editor using what I proposed last October 2009, using jhtmlarea as a tutorial work. As you can see, it's fully extensible and is not embedded with bells and whistles. I just made this in a few hours (including the demo page) so it's really an early plugin, but I really think it's a good start.

The demo is here : http://mind2soft.com/labs/jquery/richtext/demo/#demo

Comments welcome (email provided in the "About" tab)

Wichert Akkerman said

at 3:59 am on Jun 28, 2010

As lovely as much of the suggested editors here are I would really prefer to see something that does not use a separate iframe. iframes have one major problem: they can never use the same CSS as the site itself, so the text will always look different in an iframe based editor than it will look on a rendered page. This can be worked around by requiring people to write custom CSS for just the editor iframe, but that is a fragile and unrealistic approach.

I have seen one (non-open) editor take this approach and the result was beautiful, so it is possible.

Kevin Dalman said

at 11:54 am on Jul 11, 2010

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.

Scott González said

at 12:10 pm on Jun 28, 2010

Having an iframe-based editor built on top of an in-page editor would be pretty slick. If someone were to actually build an RTE from scratch, I think that would be an awesome goal.

Wichert Akkerman said

at 1:31 am on Jun 29, 2010

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.

Yanick said

at 10:15 am on Jul 10, 2010

The problem with TinyMCE is that it is not tiny anymore... The project was initially standalone and refactored to support JQuery in it's core functionalities. Howerver, much of it's code base does not support JQuery UI's widget, and it does not also respect the widget factory guidelines. Perhaps JQuery UI RichTextEditor could take some of the concepts of tinyMCE, but it is in my opinion that JQuery UI should have an official theme roller enabled, simple but solid and extensible, rich text widget. And that widget should be made without a toolbar, with all the necessary API to control it with whatever is required (JQuery UI has a toolbar widget in planning, so....)

Wichert Akkerman said

at 7:13 am on Jul 28, 2010

I agree that tinymce is no longer tiny and that its jQuery support is not usable.

I ran into another editor today which does appear to be a lot smaller and makes great use of content editable: the Aloha editor. Unfortunately its license (AGPLv3) makes it not suitable for integration in many sites.

Yanick said

at 11:21 pm on Jun 28, 2010

I still believe that this widget should not have a toolbar; but should rather have a rock solid API that can be controlled through external widgets (i.e. JQuery UI Toolbar). This would also allow "floating" toolbars, and such. Moreover, it would keep the widget clean and fully expandable. However, because a toolbar is necessary in just about (if not all) projects with a rich text editor, I would suggest to have a separate widget for that, one that would interface with the rich text editor. Something like

var editor = $('#text').richtext();
$('#texttoolbar').richtextToolbar({editor: editor]);

// change editor after instantiation
$('#texttoolbar').richtextToolbar('editor', $('#othertext').richtext());

Kevin Dalman said

at 11:14 am on Jul 11, 2010

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.

Yanick said

at 7:17 pm on Jul 11, 2010

yes, I think you make a point here. You are right that having an extra widget is unnecessarily. I like the 'showToolbars' option and your two cents about the 'toolbar' method.

However I still maintain the idea for this widget to be extensible through 'tools', and all basic functionalities should be provided as basic tools for the widget (see my demo http://mind2soft.com/labs/jquery/richtext/jquery.richtext.js)

These tools could be accessible through a method;

$('#myTextarea').richtext('tools', 'bold');
$('#myTextarea').richtext('tools', 'background', 'rgb(255,255,0)'); // third option may be whatever the tool is expecting as parameter (default null)

This way, any extra tools / features can be added through the $.ui.richtext.tools object

Yanick said

at 9:27 am on Jul 28, 2010

Github project here : http://github.com/yanickrochon/JQuery-UI-RichTextEditor (the demo page could be revamped...)

Kevin Dalman said

at 11:10 am on Jul 11, 2010

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.

Glen said

at 1:33 pm on Sep 25, 2010

I strongly suggest that no clean-up be done on the client-side, there's no use downloading hundreds of lines of JS to clean up the markup, when this can be done at the server.

I agree with Yanick that the editor should be very simple (though it should have a rich API), and be extended via plug-ins. The toolbar should be a plug-in (utilising http://wiki.jqueryui.com/Toolbar), as you might want to use a different UI (or none [keyboard-only]) for interacting with the editor.

phazei said

at 11:53 am on Oct 7, 2010

It's essential that a jQuery RTE is made easy to add custom plugins to such as your own options on the toolbar. Having a server image browser would be great, but as it's much more complicated and beyond a basic RTE, this RTE would need to be able to accommodate a custom plugin that could provide that type of functionality.

Yanick said

at 2:47 am on Jul 14, 2011

I just picked up my 1 yr old project and updated the Git repository. A demo is available at http://mind2soft.com/labs/jquery/richtext/demo/ . I haven't tested thoroughly on every browsers yet, but it should be fairly compatible with the major ones for now. At best, all features should degrade gracefully. All comments welcome.

TigerC10 said

at 1:47 pm on Feb 1, 2012

I saw (and consequently fell in love with) elRTE - http://elrte.org/demo

You don't have permission to comment on this page.