I don't think hyped-up textareas are the way to edit content in the future, or, for that matter, in the present. We should be using transparent editors and @contenteditable IMO. Way back, at an old company, we implemented a WYSIWIG editor on IE/ActiveX (I know, I know, this was back in the day) for our CMS product which made us one of the first on the market to offer live, in-place content editing. Now the time and the tech are ripe to bring that to all browsers. Imagine, instead of a beefed-up textarea entry, you just get your blog page and fill it out "live". Or your mom's little webstore. And so on. These guys are building one and want to open source it (push them to use Apache License/BSD :)): http://www.slideshare.net/draftkraft/aloha-editor-contentedi...

I'd love to see more work going in that direction. Also, they have pretty good UI ideas in that, some of which we had in Habari for a while (media silos, everything-is-a-plugin).

That looks like a great editor. But aren't (nearly) all WYSIWYG editors technically using contenteditable? The important difference seems to be that this one hides the toolbars until you start editing?

I think what moeffju means is that the whole page (or nearly all of it) should be editable, and we should be editing it in such a way that it is truly WYSIWYG, and not just merely a "rich box".

For example: Wordpress's editor doesn't usually look correct because the theme-stylesheet isn't included. Solving this problem either requires the template-writer cooperate, or it requires the editor be a lot smarter than current "rich box" editors.

I've started something that takes the latter approach at http://geocar.sdf1.org/ed/test.htm

The idea was that an Apache filter would insert an enable_editor() if the user had a logged-in cookie, but the above link just activates it in onload.

Yes, that is an excellent idea. The user interface is much better that way. The only problem I see is communicating this to the users. What would be a good way to indicate that the user can edit the content inline? I foresee a lot of "how can I edit my site" emails ;)

Current WYSIWIG editors use contenteditable or some other browser-inbuilt rich text control, with varying results. Aloha uses parts of the browsers control, but does its own selection handling, cursor handling, and formatting control. The new Google Docs editor, from what I've read, does everything manually, including layouting and rendering the cursor. So it's reimplementing RichText controls in HTML+JS.

I've had a heck of a time finding a decent markdown editor to implement into my current project. I don't want it to spit out HTML, I want markdown. But I want a WYSIWYG editor, not just a bunch of markdown shortcut buttons. Any suggestions?

If you want a WYSIWG editor, why would the storage format matter?

I think your best bet is writing a HTML-to-markdown converter.

Well because I don't want to have to worry about trusting the html coming from the editor. I probably will have to go the converter route sigh.

If that's your concern then going for a HTML sanitizer is the better route. The language/framework you're using probably already has one.

Althoug it's not built directly on top of jquery but only has integration with it I think CKeditor deserves an honourable mention.

Yeah, I am a huge fan of jQuery, but honestly none of these hold a candle to CKEditor. I recently switched from TinyMCE and it was nice that CKEditor came in around half the size and for me matches or exceeds everything else feature-wise. Plus CK new UI is much nicer/slicker/'moderner' looking than most of these.

I wonder why WYMeditor (http://www.wymeditor.org/) is not in there. Is it officially abandoned? I implemented WYMeditor for a couple of customer sites and liked it because it makes it really hard for editors to screw up the site layout.

Outside the yet another list blog post, I'm since I've adopted wkrte (http://code.google.com/p/wkrte/) as my favorite lightweight jQuery editor. Has anybody ever seen a real review of jQuery RTEs rather than an inventory?

Anything that decouples styling and formatting from the actual document is great. Mainstream users moving away from the MS Word way of doing things will make the web much more usable. Tools like these that bridge the gap are refreshing to see.

Do any of these create well formed XHTML?

To me this is the crux of the problem. People try and paste stuff from Word. It happens. All my clients need/want to do this. Whatever you think about this philosophically, a decent WYSIWYG editor HAS to be able to:

- receive Word HTML pasted into it - output valid XHTML

The only editor I know of that can achieve this is XStandard. We use it, and we hate it. It is a browser plug-in, so needs to be installed per machine, plays havoc with Windows if you try and install it without Admin rights, crashes Mac browsers, doesn't really work properly in Linux and is generally a nightmare to support. BUT, it can receive a paste from Word and produce relatively sane, valid XHTML.

Anyone that can write a Javascript-based editor that can achieve these two requirements will be rich...

markItUp isn't a WYSIWYG editor, so it depends on the user :p