◀ Merged tasks: T1304.

To provide a little more context...

Problem: Technical Userbase

One problem is that while WYSIWYG editors are better for novice and less technical users, my experience is that they're often worse for more sophisticated technical users. Personally, I find it very frustrating to format things like lists and code blocks in every WYSIWYG editor I've ever used -- they never seem to work quite right, and when you bold something it bleeds all over the place, and features like undo and drag-and-drop always have weird glitches.

The choice to use text rather than WYSIWYG seems clear in most contexts in these tools, like comments in Differential, where text is generally short and users are necessarily very technical. GitHub also does this. No one has ever filed a feature request for a WYSIWYG inline comment editor, either. My sense is that these users are fairly happy with the status quo (historically, most complaints seemed to be about differences from Markdown / GitHub Flavored Markdown, but we now support nearly all of the same syntax).

However, Maniphest and Phriction are a little different: partly, they are likely to be used by a less technical userbase, and in Phriction the size of a document tends to be much larger. Previewing a large document is fairly cumbersome with markup text.

Problem: Implementation Complexity

Another problem is that the open source implementations of WYSIWYG editors (TinyMCE, CKEditor, etc) seem to be gigantic, horrible messes that still don't really work right. "TinyMCE" is several times larger than all of the Javascript in Phabricator combined, and CKEditor is even larger.

I am very hesitant to introduce dependencies on code I can't understand or debug, and I suspect it would take me a long time to become familiar with these packages. We could also write one from scratch, but my sense is that this is also really hard.

Problem: Remarkup

A third problem is that I think Remarkup is pretty useful and an idea we should continue to pursue, but it's home-grown and won't have default support in third-party editors. So even if we just drop TinyMCE into Phabricator, we still need to write a parser/adapter step to convert the markup it produces into Remarkup, and convert Remarkup into a format it can understand. This has to work pretty well or the experience becomes even more glitchy. Doing this is likely to be technically challenging, maybe sufficiently challenging to partly motivate writing the whole editor from scratch to avoid it.

Alternative: Markup Assist

GitHub wikis and StackOverflow feature editors which are not WYSIWYG, but do assist users in writing markup by inserting markup symbols into the text. This would be comparatively easy to implement and not have any of the glitchiness/horribleness problems. However, I'm not sure how much of the underlying problem it would solve. It's useful for users learning Remarkup, but less useful for, e.g., editing large documents in Phriction.

Possibly we could improve preview behavior in Phriction (for instance, put the edit panel next to the preview panel instead of above it) to reduce the pain there, and then just get away with a markup assist editor. There are some tricky problems with that solution (how do we keep the markup next to the generated text?) but they're less difficult than building a WYSIWYG editor.

Valid points. And yes it's a hard problem to tackle, i'm also pretty fond of remarkup.

I saw http://redactorjs.com the other day, it is very well made, and just seems to do things as you'd expect. Works very well.

Somehow getting remarkup support in that would be awesome indeed, but sure how technically it would work.

I guess, unless you could somehow convert HTML back to raw remarkup, that it would be pretty difficult to maintain remarkup as the actual stored text.

Fixed toolbar (when scrolling down), and autoresize as you type is also nifty.

Redactor appears to have the same kinds of problems everything else does, at least for me. For example, when I paste rich text from another content source (like a webpage) it retains whatever (almost always undesirable) styling it previously had (kind of; some of the styling is adjusted), and "undo" stops working and fails to remove it. And when I copy/paste a block of code, it converts newlines to paragraphs. Argh!

These seem minor, but much of what I do is just copy/paste stuff into other stuff. It always works the right way in text areas, but seems to break in some subtle, infuriating way most of the time in fancy-text areas.

Redactor does seem way less bad than CKEditor/TinyMCE, but I probably wouldn't personally want to use it. Of course, I'm sure many people would much, much rather use it than write weird text markup stuff.

I think for the Remarkup to work with it we'd have to convert the HTML to Remarkup, but this isn't as big a deal as it seems, because we must parse the HTML anyway to avoid XSS. So we need a parse step regardless, and it presumably wouldn't be too much harder to have that parse step emit Remarkup instead of HTML as output.

Just throwing this out there for consideration: http://xing.github.com/wysihtml5/

One way to make live preview more useful when editing large articles would be to allow editing a section of a document instead of the whole thing - for example using headers as section delimiters. That way the section you are editing is small enough to see the live preview on the same screen.

On the other hand, using something like wysihtml5 would do away with that problem and you would not need the preview, but it would require parser/adapter as mentioned above. wysihtml5 seems easier to adapt compared to TinyMCE.

I'm not sure if I am filing this under the right task:

We use a lot of PHP code as examples in our wikipages. But the editor is by default not a monospace font. There's also not an option in the user preferences to change the font. So I use a workaround to set the textarea's font to a monospace font (via the element inspector in Chrome).

It would be nice to have an (user prefered) option to set the font of the priction editor.

I simplified my work around by adding this as a bookmark:

javascript:void(document.getElementById('document-textarea').style.fontFamily = 'Courier New');

@arnoldpistorius, there's a setting for that in "Settings" -> "Display Preferences" now (I think it got added a week or two ago).