At Open Plans we've been thinking some about Javascript WYSIWYG HTML editors lately. Kupu is the incumbent editor because it's the default in Plone, but we needed to make a more conscious decision since it's pretty key to the basic functionality of the site. I worked up some criteria for evaluation and started the evaluation; mostly what the communities and code bases look like. We're evaluating Kupu, Xinha, TinyMCE, Dojo, and Wikiwyg. I left out FCKEditor because I just didn't feel like testing everything, and something has always seemed odd about that product to me, and it doesn't seem to offer something distinctly different from TinyMCE and Xinha. If I'm wrong to leave it out, please correct me in the comments...
This first round will probably knock out Dojo and Wikiwyg. The Rich Text editor in Dojo seems peripheral to the product and project, and the larger framework is just too hard for us to track or deal with. Wikiwyg is really focused on how to provide WYSIWYG editing to people using Wiki markup; we're using HTML, and using Wiki markup just opens up a whole can of worms to ultimately create something less general and powerful than the full expressive power of HTML.
If anyone has opinions I'd love to hear them. Especially fuzzy opinions like "X just felt better to me than Y" -- it's hard to really know how good these feel without spending some time seriously editing using each editor. I guess we'll have to figure out some way to do that, but unfortunately it's not trivial to set up each one.
Update: Interestingly, I found that TinyMCE and FCKEditor are really one-man jobs. There's lots of people submitting patches and whatnot, but only one person who commits. I've update the evaluation; at the bottom are charts of how many committers there are for each of the editors; there's a lot of variance.
We've had some bad experiences with FCKEditor where I work. That may or may not have been the product's fault, but we lost a lot of time because texts weren't getting saved when we thought they were.
I've been using TinyMCE with varying degrees of sucess. It deffinately has some issues... But it's easy enough to install and configure. One thing I can't stand that I've seen almost every person get caught on is thay in TinyMCE, when you click in the empty white space below the text, it doesn't change the character position to the end. It's really simple and seemlingly nit-picky but it really makes a difference.
Also, I can limit the options people have as far as formating (a good thing), but someone can just paste in something coppied from word to get around those options (a bad thing), so I have to have a seperate filtering process.
I've had some work done with FCKeditor, and it's been something of a bitch to get to work correctly. People (clients) kept breaking it... I do wonder why you are not including WYSIWYM in your reviews, it just recently got some link love (on Reddit, at least) and it seems pretty nice. It may not do a lot, but it does try to be all semanticky about it, which is a Good Thing in my book.
I've been doing the same wysiwyg-evaluation game and I immediately fell in love with WYMeditor when I saw it.
Demo: http://demo.wymeditor.org/editor/editor.htm Home: http://www.wymeditor.org
The biggest problem is that it doesn't yet work in Safari, but I think a lot of those you listed are in the same boat, because I've evaluated them all too.
I don't know -- it doesn't particularly excite me. All I care about is HTML; I don't need semantic markup beyond that. All most users care about is what they can see; what it means is implied, and only important in so far as the meaning is clear to the reader. Writers write for readers, not for computers.
That said, I am very interested in microformat support, which is kind of schema-related (but very loose schemas mixed in with content). I don't think anything has that now; part of why the community and code matters to us is because we want to build on this, we don't just want to use the product. A more semantic/abstract editor has some advantages here; but I'm not sure it's enough of an advantage, especially compared to a more mature product (and maturity really matters for this case, as there's tons of little usability issues).
One of the plugins I like for Xinha is the stylist plugin (to see it you have to look at the demo and select Stylist). I think there's some hidden potential in that, or something based on it.
# Ian Bicking
Wow, I really like that WYSIWYM editor. That fits the web perfectly. I always thought that the problem with WYSIWYG editors is that the process is of "styling" the information, which doesn't really fit the way we deliver the web (CSS+XHTML). But the WYSIWYM definitely fits that model.
I'm sold.
# Brantley Harris
It's actually somewhat surprising to me just how well most WYSIWYG editors respect CSS styles, with no special work to do it. I guess a testament to the underlying browsers' editing. Usually you have to pass a stylesheet in (so it can be loaded in the iframe that most editors use), but once you do that it's all just magic.
They still usually included non-semantic controls. But you can just take those controls out; again, adjusting the toolbar in most of these is easy. If you took those bad controls out (e.g., color, font), wouldn't you have something very much like wysiwym?
# Ian Bicking
No, I don't think so. The idea of WYM is that you have something broken away from a context of the presentation. Instead you have something embedded in the structure of the very ideas. I think the practicality of it requires some formating elements to be displayed in the WYM-editor, i.e. bolding, italicizing, unordered lists, etc. But in the distant ideal those would just be highlighted and marked as such, rather than actually displayed as such.
In TinyMCE, at least, I can remove the controls from the toolbar, but someone could just paste something from word to circumvent my restrictions (especially annoying). Although, admittedly, I haven't looked for many fixes for that.
I think the idea of WYM could be expanded beyond just web-publishing. I imagine a collaborative screen-writing application. I should just go ahead and patent that right now, anyone have any capital for a startup?
WYM can't keep people from pasting HTML. It can try to clean that HTML (though it's rather tricky to do this, and given its age I suspect it doesn't). Several of the other editors have special code to try to clean up code pasted from Word; they also include different kind of cleaners, some which are applied on save and some which can be applied on paste.
However, I hate opinionated editors. Legacy HTML is important. HTML with differing opinions is important. If you are doing green-field content development I guess WYM could work, but I'm more interested in content development that builds on the content we already have. The words matter more than the form.
# Ian Bicking
I assume you mean WYM-Editor? and not WYSIWYM?? .. _WYM-Editor: http://www.wym-editor.org/en/ .. _WYSIWYM: http://mcs.open.ac.uk/nlg/old_projects/wysiwym/
I don't have edit access to the WYSIWYG wiki page (http://www.openplans.org/projects/opencore/what-wysiwyg-is-up-to) -- not surprisingly -- so for what's it's worth, we have some documentation available for Kupu on our learnplone.org site per your UI requirements/goals bullet on end-user documentation.
See: http://learnplone.org/documentation/video/editing-the-body-text-of-a-page/view http://learnplone.org/documentation/glossary/kupu/view http://learnplone.org/documentation/faq/i-can-t-see-the-visual-editor/view http://learnplone.org/documentation/faq/web-browsers/view?searchterm=kupu http://learnplone.org/documentation/tutorial/quick-start/editing-the-body-text
All of this is under a a creative commons license and we're even delivering the site via lightly customized themes via different urls.
See: http://learnplone.onenw.org/documentation
More info about the learnplone.org project at: http://learnplone.org/about
Obviously, it all could use some editing, work, and polish and we plan to continue putting resources into it at ONE/Northwest.
Yeah, but is there documentation on how to make Kupu work in a non-plone setting?
I really really really wanted to like Kupu. The Plone movies were breathtaking. But I'm not using Plone. We have a custom Zope 3 based CMS. I tried and tried and tried to figure out how to customize Kupu to fit in our environment, and it was damn near impossible.
Kupu's ability to do things like find images and links in the CMS are great. I think that's one of my favorite potential features. But the developer documentation was of little or no help. And the package layout seemed geared in such a way that the only way to add third-party / custom support was just to do it inline with the rest of the package, which sucks as it makes upgrades difficult. It seems engineered exclusively for the projects and people who are working on the core.
We went with TinyMCE instead. I'm not a huge fan of it, but it was the easiest to get up and running.
I still want Kupu - I think I can deliver a better user experience for our customers with it. But for all of its claims of modularity, I found Kupu to be very developer hostile.
Both Xinha and TinyMCE have plugins for image and link management. They don't currently have Plone integration, of course, but one hopes that is simpler than writing it from scratch. (Actually last I looked Xinha required a full enumeration of the site for at least some of its plugins, which isn't feasible and would have to be fixed)
I dislike too much out-of-the-box Javascript/backend integration, and much prefer formal interfaces (i.e., documented APIs). So I tend not to put too much weight on existing integration work.
# Ian Bicking
Being FCKeditor the most used editor out there, I really don't believe it was a good move to take it our of the evaluation. Anyway, we have been using it with great success.
# anonymous
The ability to create structured content is sorely missed in these wysiwig embedded editors.
These projects miss the main need here; it's not really how to make the fonts pretty or large. It's how to code content in a way that's ontologically meaningful.
These editors should contain a dropdown list of elements or at minimum element classes. The problem is that it's nearly impossible to reuse this content via conversion into a meaningful xml dialect. You have almost no way to create an embedded microformat here either.
Example, I deal with poetry publishing. Using p and br tags to code stanzas and indents is of little use to me. If they had more structured markup, then conversion scripts could easily be written.
there are solutions in the commercial/enterprise CMS world, but they are costly. For me, this feature is the most important feature for editors, and no editors for plone have this.
I've had a much better time working with TinyMCE than anything else out there. It also seems to return well formated XHTML, which has been very nice.
# Chad Crabtree
I did a similar evaluation a couple of years ago and ended up with TinyMCE. One of the reasons is that TinyMCE treats <Return>-key as a new p-element. The team (or the man) behind TinyMCE seems have the "right" attitude regarding web-standards in general. It is also important that TinyMCE supports Opera after Opera added support for content-editable in version 9 or something. Though in Opera the <Return>-key generates br-elements. I have the understanding that this will be fixed in the future by Opera. The Safari support is probably limited.
# Andreas R. Johnsen
Better late than never - thought this was a pretty good evaluation: http://www.standards-schmandards.com/2006/wysiwyg-editor-test and the full results here: http://www.standards-schmandards.com/exhibits/wysiwyg/result.html
# Harry Fuecks
Cameron Adams made a nice (and simple) WYSIWYG editor a while ago. Maybe you'd like it: http://www.themaninblue.com/experiment/widgEditor/
I've used it several of my own projects and it works very well.
Ian-
Given that Kupu is Plone's default editor, and is probably likely to remain so for a while, I think it would be tremendous if OpenPlans invested its considerable energy and talent in identifying and fixing whatever warts Kupu has (and it certainly has them). I'm sure Duncan & the other Kupu maintainers would appreciate the help, and your efforts will have an immediate and massive benefit to the entire Plone community as well as to the OpenPlans suite.
OTOH, if you really think Kupu is problematic (and perhaps it is) then that's also a conversation that should really be taken out into the wider Plone community.
We won't be choosing Kupu, but we will be making a component for the editor of our choice to integrate into Plone, and adding some of the integration features that Kupu currently has to that editor.
As for the larger conversation, well... I hate asking communities to Make Big Plans For Change. We'll see how this goes for us, and what other people with different use cases think, and then when there's a concrete choice on the table we can revisit this question for the larger Plone community from a more informed position.
# Ian Bicking