Use markdown instead of tinymce in the community

[ewinslow]

Mostly I want this because pasting code looks crazy ugly in the community right now and I don't want to have to ask people to post snippets on github all the time.

Is there anything critical to the community that tinymce gets us that markdown can't?

[cash]

We have a lot of naive users who won't know markdown. We'd need a WYSIWYG that supported Markdown editing - even then most users would continue to paste in code directly.

I have a half-written plugin that provides a pastebin like capability to Elgg...maybe integrate it into a WYSIWYG button with Ajax pop-up for pasting code. Would still take a while for the community to adopt it.

[ewinslow]

What formatting is tinymce making easy for the naive users? Do they even need more than a plaintext field?

[cash]

links are the most common - you see some bold, italic, images, and lists too.

[ewinslow]

What if we just put a link to a popup or something that explains a few of the common formatting options? If they really need it to they can learn to use it, otherwise I don't see us losing that much by switching.

There are some other benefits of markdown too because we can use a plain textarea: mobile-friendly (this affects me quite often actually), no delayed rendering, opportunity to implement/use username autocomplete that isn't tied to a particular editor.

[brettp]

Raw links get linkified during output, so that'd be a similar functionality.

The majority of the times images are for huge screenshots, which breaks the design. A link to the image would be just as useful.

I'd say of those, lists would be the most important from an information dispersal / consumption perspective.

I don't think we gain much by having TinyMCE on community, but I also don't think people would like the change of removing it without replacing it with a similar WYSIWYG editor.

[mrclay]

A few practical questions, about using Markdown anywhere...

1. All existing posts will be HTML and cannot be converted to MD. How do we maintain compatibility?
2. How do we allow later editing of entities? Would they edit the MD version or the converted HTML?
3. At what point would the MD converted to HTML? Is the HTML stored in the entity (see number 1)?
4. At what point is input run through Htmlawed?
5. Would running the (plaintext) MD through Htmlawed be sufficient, or must we filter the *output* of the MD converter? Or Both?

FYI ManUtopik is working on a MD-based wiki with a MD JS port used for preview, but I haven't played with it.

[ewinslow]

1. MD allows HTML. No need to convert. Also,

2. Edit the originally authored MD version.

3. We can save the original markdown in authoredDescription (or something), and the parsed version in description, as normal. One for editing and one for displaying (so we can avoid running the parser every time a user views the page).

4. Before being output to the page.

5. Filter output of MD converter. I would think.

[mrclay]

Practical steps:

1. Create option to enable Markdown authoring in group discussions (covers most of community)
2. Use lessons learned to create content API and conventions for general usage.

API should maintain name of authoring format because not all will support HTML entry, and even with those that do, presenting HTML in a textarea is bad UX, and HTML round-trips through the converter could introduce artifacts.

[mrclay]

Or we replace step 1 with "design full plan of implementing MD in group discussions" (we might gather enough requirements for the API without actually having to code a full implementation).

[ewinslow]

I like your proposal of trying it out on the community and using lessons learned to flesh out something general.