As one of the more vocal participants in the previous discussion, I have a lot to say on this, so be patient 
First of all, on the feature set: I’m actually somewhat opposed to the idea that we allow open-ended creativity in terms of creating complex HTML, in favor of a more restricted set of styles. Here’s my reasoning: I strongly support the mission statement of Discourse, which is “civilized discussion”. I think that to the extent that styled text supports that mission we should allow it. But this is not a word processor or desktop publishing software. In particular, I don’t want to see people go crazy with fonts and colors.
What I would like to see is styles that correspond to useful semantic meanings. So for example:
- headings are important because they break up text into logical sections.
- block quotes are important because there’s a lot of quoting in these discussions.
- bullet lists are important because they help organize thoughts.
- images are important because a picture is often worth a thousand words.
- source code formatting / preformatted text is important because some ideas can’t be expressed easily in a proportional font.
But things like pink text on a green background? Or comic sans? I could easily do without either of them. Ideally, one might think of each post as an academic publication, where variations in style from one paper to another are frowned upon.
Now, as to the engineering details:
-
One of the objections cited was the difficulty of round-tripping between markdown and HTML. However, that problem can be solved, I think, by only supporting a strict subset of HTML. For example, Markdown supports tables very poorly compared to HTML. So the solution is to either disallow tables, or to don’t convert them (i.e. embed the HTML table directly into the Markdown as HTML blocks).
-
One major area of concern is the plugin API. A WYSIWYG editor might not have the same DOM structure as the existing compose editor, and this might break some plugins. I haven’t really looked at the editor plugin API, so I don’t know how isolated the plugins are from the editor internals. Someone who knows this stuff better might be able to chime in here.
-
CKEditor has a Markdown plugin which allows the editor to save in Markdown format instead of HTML. However, CKEditor is also huge and has tons of featured we don’t need. I only mention it here as an existence proof of what could be done.
-
I’ve been doing a lot of my own experiments with TinyMCE. Before I started looking at Discourse, I was working on my own forum server using Meteor and React, so I’ve had a fair bit of experience with it. TinyMCE does a lot of what you would want, with a fairly low footprint, although the API takes some getting used to. One of the nice things is that they host it for you, so all you have to do is include a link element in your HTML. (Although if you are going to be doing any serious customization you have to download and host it yourself.)
TinyMCE also supports several different editing modes which are interesting. There’s an ‘embedded’ mode which takes your textarea and replaced it with an iframe which has a standard-looking toolbar. There’s also an ‘inline’ mode which works on block elements (not textareas) in which the toolbar kind of floats above the editing window. (Medium also has a WYSIWYG editor similar to this, but it only supports like 6 styles I think.)
- There’s also Summernote, Froala and others. Summernote is not nearly as polished as the ones above, the docs are written in very poor english, however if you were going to write your own editor it might be a useful starting point since it’s smaller than the others and has fewer features.
The question with all of these choices is whether they support the exact feature set that you want. So the first thing, I think, is to decide exactly what styling features are must-haves, nice-to-haves, and so on. If none of them will work then it’s time to start thinking about writing your own content-editable.
-
Another issue to consider is sanitization, although I suppose that Discourse already does this. Both CKEditor and TinyMCE will strip harmful attributes and tags from the input, however you still have to sanitize on the server to prevent people from bypassing those safeguards.
-
TinyMCE and CKEditor also support callbacks for image uploads - that is, pasting an image from the clipboard and having it turn into a URL which is hosted by the site. (I was please to see that the current discourse editor supports this. I was even more pleased that it works with SVG files, which is very important to our users who frequently share graphs and charts related to clinical trials.)