Hello,
I’m about to start working on a simple rich text editor for a specific project. I’ve been looking around at various tutorials, and all of them describe it using ‘ugly’ elements. I also noticed that they were all at least 3+ years old.
So, before I get started I thought I’d ask: what are the best elements to use for a RTE?
Should I use an editable div, iframe, etc.?
Anyone have any more recent tutorials?
Rich-text editors are a difficult enough to do well, and the established free options refined enough, that I would strongly recommend you use (and customize) an existing solution such as TinyMCE rather than trying to write your own.
I suppose that’s why there aren’t any recent tutorials around—most people have come to the conclusion that rich text editors are not a wheel that is worth reinventing.
Definitely. There are so many good ones about as it is. If you’re super keen to write your own, you can do worse than examine those ones to see what’s happening.
The artist formerly known as FCKeditor is now CKeditor and looks pretty slick: checkit. It’s not as much fun to say out loud though!
If you plan to use jQuery, you might like to see how this is put together.
Other options include the YUI editor, which manipulates an iframe, and it is quite sexy!
I couldn’t agree more with Kevin.
Rich text editors are complex. There are too many things to consider, innumerable edge cases to address, and too many kinks and knots to iron out (mainly because of browser inconsistencies) before a decent editor can be cranked out for production use. Existing solutions like TinyMCE have been perfected over a long stretch of time through constant development and testing. Writing a replacement from scratch is a grueling endeavor and may slow down your project.
If your project still requires that you MUST write one yourself, start with a lightweight editor and build on the top of it. There are a number of jQuery based editors that are lighter and barer than TinyMCE is. The best way to learn how a text editor works in its entirety is to tear it apart and explore the innards, I am afraid. I am unaware of any single tutorials that does this for you. But I believe that you definitely can search for tutorials that treat the subject in piecemeal.
It’s important that you think of the user up front and what you want them to be able to edit. If the audience is developers / technically minded people I would strongly reccomend you look at plain text solutions like this forum uses: http://markitup.jaysalvat.com/home/
If you do want a HTML editor I would then recommend http://www.wymeditor.org/ as I love it’s simplicity and the fact that it doesn’t represent exactly what the html will look like (shows the elements used).
That being said I’ve written my own rte from scratch using the popular textarea / editable iframe switch and it has taken quite a beating and come out on top. I’d disagree that is such a complex undertaking that you should stay away completely - but it’s worth asking the question why you would write your own.
If you are very comfortable with HTML and Javascript and the features can be kept simple(bold,italic,align,numbered list,bullet list,indent,outdent,undo,redo,edit source) it’s not a ridiculous amount of work.
Sorting out paste is one of the tricker parts (some people avoid that though with a special paste from word feature). Happy to help if you want to give it a shot and run into problems 
–
These are essential reading:
http://www.mozilla.org/editor/ie2midas.html
and here is the basic shell of my version:
RichTextEditor = {
// Create an array of hash groups with the default tools that use execCommand
tools: [],
init: function(textarea) {
},
createDocument: function() {
},
updateTextarea: function() {
},
updateIframe: function() {
},
toggleSource: function() {
},
formatSelection: function() {
},
addContent: function(content) {
},
setContent: function(content) {
},
getContent: function() {
},
editorCommand: function(command, options) {
},
getSelection: function() {
},
getSelectedContainer: function() {
},
submitHandler: function(event) {
},
editorKeyUpHandler: function(event) {
},
cleanHTML: function() {
}
}
Keep it simple :tup:
YUI editor, TinyMCE and CKEditor are very capable and well documented.
The YUI editor hasn’t been around for as long, so it’s had a bit of catching up to do, but a colleague and I extended the examples for file upload / management and found the editor to be well put-together for extensibility. The bit that lets it down is the code produced. It’s easy to produce a real mess of markup behind the scenes after only a minute or two’s use of the editor control on a web page, sometimes to the point where you can no longer undo everything using the toolbar controls.
If you could post a reply about why you’re looking to build your own editor then maybe people could address that question more directly?
This website has loads of pre-existing solutions, why would you want to reinvent the wheel?
I’ve tried a couple in the past but they are very well documented, highly flexible and very agile (in terms of their code)
The reason I’m interested in writing my own is because what I’m going to be creating basically isn’t a rich-text editor.
Essentially, there is a body of text and another separate control. What you do is select a section of code, then do something in the other control. It then basically places the text with a span that hides a little bit of data with it (similar to the common anchor text functionality of WYSIWYG editor).
Due to this, even the most light-weight existing RTE is still overkill.
Also, due to some of the restrictions on the project, it basically needs to be written from scratch.
Anyone care to indulge me a little and just let me know the basic elements that are best used for a semantic, standards-compliant RTE? I have an idea of how I’ll do it, but before I got started I wanted some input.
Thanks.
What’s the control you mention that would do something with it, is it something like a bad words censor?
No, it’s Google Maps. =p As far as the RTE goes, it’s completely unrelated. GM just gets the selected text and does some stuff with it.
Assuming you are talking about ranking top in search engines, step one would be to not post about it in a topic talking about Javascript rich text editors.
Step two would be to take a look at the Search Engine Optimization forum for lots of great tips.
Is it something like Google Maps takes the text and zooms in on a location mentioned in the text?
You are editing html so the textarea should be the base.
If you have a list of tools add a list, use an iframe for the editable area.
Wow, interesting… just last night I was at a meeting where this lawyer, Koen Willems, told us about the way that the lawyer-guys in the municipality of StadsKanaal dealt with the problem of editors (as WYSIWYG’s) are the weak point of any site, if you want that site to remain compliant with web standards. They had worked hard to make their site the first in the Netherlands to follow the webrichtlijnen, which are basically the Dutch rules for web standards based heavily on WCAG1 (they’re working for this summer WCAG2 version to be done).
What they ended up doing was taking the FCKeditor and heavily modding it. They call it a WYSIWYM (what you say is what you MEAN) editor. The users (who are mostly like lawyers and other non-IT people) need to set what the text chunk MEANS. And each chunk is highlighted in a different colour, where you can say “this is a header” or “this is a paragraph” or “this is a definition list” (those had to be wrangled a bit because ordered definition lists needed to be unordered lists inside definition lists… something about, if part 1c is removed, you can’t let the browser move part 1d up and call it part 1c… interesting).
Willems also showed us how semantic, complex tables were made by users of this special WYSIWYG editor.
It was pretty cool. Someone might still want to comb through the results but the editor seems to manage to do a lot of the work itself, checking for things.
It did demand a summary att for tables but I’m not sure who checked to see that the summary was appropriate.
We told the guy they should make it open source. Who knows, maybe they will. The idea of starting with the base of FCK/CK and being able to add plugins of some sort to make the editor be able to deal with certain user sets and pass out standards-adhering code is awesome.
Someone in the audience said there was someone in Germany working on something kinda similar.
Can’t tell you, yet. =p (But no, it’s not quite that.)
The problem is textareas can’t contain other elements, so…
What a timely post- I am also attempting to embark on a RTE project, and have basically received the same advice- don’t reinvent the wheel, just go along with someone else’s work. I have to say- that’s very frustrating advice, because we all have to design wheels for our specific vehicles… (not to take that metaphor too far).
I think a good discussion would be what element should be used for the “editing” part of the text editor. Of the following suggestions:
I think an iFrame might be the best solution- but not necessarily standards compliant. Here’s a question: will we have an easier time with this in HTML 5? What about manipulating the canvas element?
All three of those - frame, iframe, and canvas are better off replaced by an object element. Since an object can do everything any of those others can do and more plus it is a part of the current and future standards.
The textarea is the base element, without javascript you can enter HTML into the textarea.
With unobtrusive scripting you add the iframe of the same size and hide the textarea.
There are other options like using the canvas element https://bespin.mozilla.com/ but the guy who made it is quoted for saying “If I had known how hard it would have been I wouldn’t have bothered.”
Can you explain how an object can be used like a window?
The object element has always seemed like a magical element that can be used to embed other media types in the document. I wouldn’t have thought that would be appropriate here.
Most advice is assuming this is for a commercial project where time is money. It’s not a simple undertaking and there are large differences between browsers so with that in mind a free one is the best option.
But if you want to learn more about javascript and are interested in the ins and outs of an rte I found it to be a very profitable learning experience.
The iframe is the only logical element from that list.
Text isn’t an element.
Textarea’s can only handle plain text and the form element is quite limited in some browsers.
You could use a div with contentEditable enabled - one problem with this is that because it is part of the document it will inherit all the styles of the page unless you explicitly override them. You also can’t include an external stylesheet. I haven’t tested this cross browser yet but http://www.yellowshoe.com.au/learncss/1.html is an example of what that could look like.
A frame isn’t suitable for embedding in pages, it needs to be in a frameset and can’t be dynamically inserted in the same way that an iframe can.
Yes time is money- but so is space. I think what we are discussing here is trying to build custom editor that serves a specific purpose, and is not simply a stripped down version of much heavier RTE built for bloggers.
For instance, one of my old projects (in vague terms to protect my employer) required the ability for users to edit a custom markup language (lets call it ArticleML) rather than XHTML like we are discussing here. Instead of bold, italics, underline buttons- there should buttons that format the text specifically in ways that my users understand (like a biography tag or a reference tag). These tags are then styled according to XSL… etc. etc. etc.
RTE editors are interesting because they convert plain text to markup- they are not “styling” the text. We know that just because it appears bold in the RTE means that it has <strong> tags, which represent something structural. These visual clues indicate to our users what the structure is.
In conclusion, this seems like a very useful exercise for commercial purposes.
Text isn’t an element.
Yep, my bad… and I didn’t mean <input type=“text”> either. Using the RTE comment editor in the Sitepoint forum, I accidentally hit enter while typing Textarea and ended up with that stray list bullet. Due to my bad editing, it remained. Lucky for me it did, what a great example about the problems that even the current editors have- and why we perhaps should not jump into using them simply because others tell us they are “the wheel”.