Monday, October 23rd, 2006>p>Abe Fettig works on JotSpot, which has evolved its rich text editor as new releases have come out. People have a love hate relationship with WYSIWYG, especially developers, and Abe started out there:
“I didn’t always like WYSIWYG”
He starts off redefining what most people think of WYSIWYG. It doesn’t mean Microsoft Word. vi can be WYSIWYG. If you are editing a text file you see what you are getting.
In fact this is a definition of WYSIWYG:
“EMACS was one of the very first WYSIWYG editors, replacing (actually, at first overlaying) the extremely obscure, command-based TECO.”
WYSIWYG is WYSIWYG if you do not have to imagine what the output will be.
WordPress Editor Example
Abe created a WP theme that changes the default WP behaviour for editing:
- user comments: lightweight wysiwyg: the div it grows, url recognised. simple.
- admin post: edit inline instead of going to the edit page in /wp-admin
Abe next went into some nuts and bolts, getting into details on document.designMode=”on”, contentEditable, and document.execCommand.
The bad news is that browsers differ a lot here, which means that if you are writing to this low level you are in for a lot of browser checking work.
Abe shows how we can build editors, but quickly warns us from doing so.
I have seen enough to know that I sure as hell do not want to write my own rich editor.
The Dojo editor was the obvious example to see how much easier it is to use an editor that is out there, versus writing your own, and we should plug it into our template at ajaxian.com.
Watch out for the following in rich components
- Custom undo/redo stacks that work
- Spell check: FF2 has it, gmail has it. Goal: cross browser inline spell check that works
- Zimbra ALE: embedding rich objects in WYSIWYG using iframes
- Advanced plain text editing: grok code and syntax