Markdown as first class citizen

[ionsulei]

@bernardosulzbach

I have been impressed before in other projects by how non-technical people push back on Markdown, so it doesn’t surprise me as much anymore.

It’s all about UX. One way to approach it is to make the default what non-technical expect and have the more “advanced” mode/features hidden but accessible when needed. Simple by default

@kolaente

The biggest problem here is back when the editor was Markdown only, users complained about the lack of WYSIWYG. Now that we have WYSIWYG, users complain about the lack of Markdown.
Unfortunately, we don’t have the resources to maintain two editors in parallel, so we need to find some middle ground in between.

@kolaente my point was that that you can accommodate both with a single editor with better UX, if the text parsing/rendering/storage is modular, but it’s indeed harder

@kolaente

So far, this middle ground has been markdown shortcuts in the WYSIWYG editor.

The issue with those is that most of the time they don’t work and don’t produce the expected markup (HTML). The table input is UX is really nice though

---

My major markdown pain points:

• Pasting from somewhere else / writing without the MD shortcuts

  You can save them but they will not be recognized and rendered as the editor / UI expect everything to be only entered with the WYSIWYG shortcuts

• Interoperability when using 3rd party clients (especially CalDAV)

  Most if not all CalDAV clients expect text fields (summary,description, comments) to be in plain text or plain text markup mostly markdown.

  If you create/edit tasks in any of those clients, sync and open in the webui, newlines are stripped and the whole content is placed in <p></p> tags. This makes it unreadable and when you sync back to the clients they get the redacted content in the paragraph tags without newlines which in turn breaks it for them too.

  On the other hand if you create the task in the webui the CalDAV clients will get HTML instead of pain text and thus make it human unreadable and uneditable.

If you think about it the issue is one and the same, and is less about markdown and more about how pain text is handled. Stripping newlines is definitely a bug.

Speaking about newlines if you create a table, code block, blockquote in the WYSIWYG editor and you have no newlines after it there is no way to exit and create a newline.

Probably the easiest win as far as the webui goes is having Raw support in the editor so that you can work only with pain text without it getting mangled and processed.

---

Some napkin ideas

I’ve seen several projects making use of the monaco editor (what vscode is build upon) and this comes with some great advantages out of the box such multi-select, multi-cursor, built in keyboard shortcuts and a lot more. It can be extended with overlay WYSIWYG shortcuts…

Not sure what editor discourse forum is using but looks like it ticks all the boxes, supports input of both pain text markup (markdown/ bbcode) and HTML, preserves it during edits, has raw input and previews.