Symphony.

I noticed that the WMD editor extension is no longer being developed:

http://getsymphony.com/discuss/thread/36833/4/#position-67

Although there are other WYSIWYGish text formatter extensions, this one seemed the 'official' one for Symphony.I've definitely been using it a lot. Is anyone planning on maintaining it? Are there plans for something better? Is one of the other current options recommended as a replacement?

i think a lot of us have switched to markitup

GitHub's Gollum-project also has a really nifty editor that supports multiple markup variants, has a nice editing interface with inline help and functions as an extensible jQuery plugin.

I've been thinking that it would make a great Symphony extension, but probably don't have the skills to implement it myself. But if anyone wants to take a stab at it, I'd be happy to help and applaud!

Ooo, Gollum is pretty.

SmartMarkUp has been around a year or so and I've always liked it. Possibly worth a look?

http://code.ge/smartmarkup/

i think a lot of us have switched to markitup

Yup, true for me.

GitHub's Gollum-project also has a really nifty editor that supports multiple markup variants, has a nice editing interface with inline help and functions as an extensible jQuery plugin.

Love it and license has no use restrictions.

Last week, Simone and I talked about an interface for a Symphony editor. Maybe this can be combined into a new text-formatter. I'll chat with him about that - or he steps by and posts what he thinks :)

Maybe this can be combined into a new text-formatter.

I don't think that developing a new text-formatter is a good idea (we have Markdown which is a really good one). If I get it correctly, what bewildergeist was suggesting is to bundle Gollum's editor in a Symphony extension. Am I right?

Last week, Simone and I talked about an interface for a Symphony editor.

Everyone: The idea was to design a skin for CKEditor, which is a pretty complex editor with tons of both useful and useless functionalities. In an ideal world where every of us has a lot of free time, we would develop a WYSIWYG editor ourselves :)

However, since the problem of choosing the right (WYSIWYG?) editor is a big one, we should consider asking Symphony users to vote their favourite. We could then develop a skin for the two most used editor. What do you guys (Nils included of course ;)) think?

It is also important to distinguish between editor for clients and editors for Symphonians. Clients need a full-featured editor like CKEditor, while Symphonians should be ok with something like MarkItUp (it could be used in place of WMD on this forum, for instance).

Keep posting your thoughts, please!

I'm with you. I updated TinyMCE the other day and tried to tidy it up. I spotted they had a media manager and a few other nice bits and pieces, which would make it really powerful. If CKEditor editor is considered better, let's use it.

We totally should not reinvent the wheel and developer a WYSIWYG editor of our own. It's a massive time sink. It's why so many are started but never completed or updated. So we should try to unobtrusively skin an existing, well-supported editor.

I don't think that developing a new text-formatter is a good idea [...]

I should have said text-formatter interface in my comment. What I wanted to say is that this may be a good start to create a general Symphony text-formatter interface. A simple one. One that could be applied to different text-formatters.

We totally should not reinvent the wheel and developer a WYSIWYG editor of our own. It's a massive time sink. It's why so many are started but never completed or updated. So we should try to unobtrusively skin an existing, well-supported editor.

This is my opinion, too. Developing a WYSIWYG editor is like hell. I tried it once and failed.

Just to second Nick's remarks: do not attempt to create a WYSIWYG editor: it's actually a very hard challenge to solve…

My experience is that CKEditor is quite good but TinyMCE has come a long way too (it used to be awful).

I would definitely vote for something between WMD and CKEditor though: in my experience it is best to not give clients too much control over markup/formatting. Also: I would definitely go for something that's based on a 'structured text' approach: Markdown, Textile, or http://camendesign.com/code/remarkable (there's a JS spin-off just started: http://epsilon-not.net/misc/unremarkable.js )

The best approach would, imho, be something like a (more semantically focused) WYSIWYM (What You See Is What You Mean) editor. However I don't think the current editors (such as http://www.wymeditor.org ) are quite ready and stable enough...

On the other hand: many clients require something of a 'File Manager' or that will allow them to manage and handle images/documents. 'Bigger' editors such as CKEditor and TinyMCE have this built-in. I would personally prefer a separate Symphony Extension.

in my experience it is best to not give clients too much control over markup/formatting

Likewise, but sometimes it is not avoidable and we have to let clients right-align text or insert images. So if we can get a decent skin onto one of the big WYSIWYG editors then it'll fill that gap.

As Simone says, developers and users wanting to remain lean can use a Markdown editor (WYSIWYM) and existing media management (Subsection Manager?), but when we need bloat for clients, TinyMCE/CKEditor with their own asset managers working (but skinned to integrate seamlessly), would be awesome.

Agreed. One thing I would like to add, though, is that it's still probably very beneficial to tweak both CKEditor and Tiny. Both editors allow configuring the available buttons/actions. A good 'middle-ground' imho would be to make the editor as 'bare-bones' possible, stripping out unnecessary formatting options.

A good 'middle-ground' imho would be to make the editor as 'bare-bones' possible, stripping out unnecessary formatting options.

Right. As far as I know Giel has done a good job on CKEditor, removing some undesired buttons/functions.

It would also be great if whichever WYSIWYG editor is used, it's stopped from enforcing the wrapping of p tags around images. I think it can be edited in Tiny's config somewhere, but it's infuriating and makes floating images a pain.

it's stopped from enforcing the wrapping of p tags around images

That can also be done quite easily using the Ninja HTML manipulation technique.

eKoes: If I get it correctly, what bewildergeist was suggesting is to bundle Gollum's editor in a Symphony extension. Am I right?

Exactly. Gollum's editor contains all the frontend editing logic, buttons, help files etc, and supports a host of lightweight markup languages. So an extension could simply activate the "frontend" editing interfaces for whichever text formatters are installed and available. Wouldn't that work?

Clients need a full-featured editor like CKEditor, while Symphonians should be ok with something like MarkItUp.

I respectfully disagree. If those of us who "know what we're doing" prefer Markdown (et al), shouldn't we educate our clients and teach them to have the same preference? WYSIWYG editors are A World Of Pain™, and it is a tragedy to behold how many man hours have been sunk into their development over the years, and how crappy and inconsistent results we still get out of them.

I think something like the Gollum editor's built-in guide/help system goes a long way to help newcomers understand e.g. Markdown.

davidhund: I would definitely go for something that's based on a 'structured text' approach.

Amen to that. I wrote my master's thesis on why structured text formatting is still superior to WYSIWYG editing for most word processing tasks, so I'll be happy to supply academic references in support of such an approach ;-)

Nils: This may be a good start to create a general Symphony text-formatter interface. A simple one. One that could be applied to different text-formatters.

That would be totally awesome. Amen to that too!

nickdunn: ...we have to let clients right-align text or insert images.

...and that's one area where Markdown can be limiting, especially for users who don't know enough HTML to use full tags when needed. But Textile allows the user to easily add class/id to elements, so image floating and text alignment could be handled by a handful of classes that the client could insert on tags. Or simply through Textile's support for inline styles as in `p=. Centered paragraph" etc.

Inserting images is an issue, but I'd much prefer adding basic file management / upload capabilities to a Markdown/Textile editor rather than implementing a full WYSIWYG editor just for that. Wouldn't that work?

If those of us who "know what we're doing" prefer Markdown (et al), shouldn't we educate our clients and teach them to have the same preference?

While I share your point of view, I don't think it's always possible to educate clients in that way. In fact, it strictly depends on the client you are working with. Some of them just want to center a paragraph without caring about special syntaxes or workarounds.

But Textile allows the user to easily add class/id to elements, so image floating and text alignment could be handled by a handful of classes that the client could insert on tags. Or simply through Textile's support for inline styles as in `p=. Centered paragraph" etc.

My feeling is that Textile is too complex for clients. I like Markdown because it's extremely simple to use (at least for people that know what they're doing ;)) and doesn't "clutter" the syntax with special tokens for the presentation layer. Textile is losing its focus, in my opinion.

sometimes it is not avoidable and we have to let clients right-align text or insert images.

I tend to be with Nick on that.

I like Markdown because it's extremely simple to use and doesn't "clutter" the syntax with special tokens for the presentation layer.

I totally agree, and I switched from Textile to Markdown several years ago for the same reason. But if you need to add classes or IDs to anything in Markdown, you need to break out into HTML. Textile takes you a fair bit further before that becomes necessary.

But Textile is very much a shorthand for HTML and requires you to understand HTML to use it effectively. Markdown is a shorthand for structured text formatting, and just happens to be well suited for HTML text composition (it's also awesome for creating LaTeX-formatted PDF documents, btw).

While I share your point of view, I don't think it's always possible to educate clients in that way.

Dammit, a man can dream, can't he? :)

@bewildergeist: Thanks so much for the link to the gollum project. They pointed to MathJax (to render maths in webbrowsers), which is just what I was looking for.