writing/pasting markdown in the WYSIWYG editor is mostly not properly recognized or very limited
if the content is saved with the WYSIWYG editor it will be stored as HTML and not markdown. This is problematic as if you sync the task with CalDAV client like JTXboard that expects the text fields in markdown and are then natively rendered as HTML or expect the API to return markdown to be handled downstream
The opposite is also broken. If you create description/comment fields through the API or CalDAV in markdown they will not be recognized and rendered to HTML in the Web UI
Some ideas how to fix
Make text processing modular breaking it down to 3 separate steps - 1) Markup storage 2) Rendering 3) Editing
1) I see to approaches for that. Have some kind of normalized format for storage (maybe can be just HTML) and return desired markup on request or the simply store the raw markup. Probably storing only the markup is better and cheaper. Users then can choose the default global markup, and later can be changed on individual project/task level. This will allow to support multiple markup languages - markdown, org mode, asciidoc etc.
2) Rendering to HTML should happen on runtime for the given markup on server or client side. When requesting with the API usually you only need to return the raw markup but there might be an option to return rendered markup if desired (for the fronted for eg. if rendering is server side)
3) As with rendering, editing depends on the chosen markup. The editor can be the same for all languages - for example WYSIWYG bold for markdown will output **fdsaf**, for org mode *fdsa* and etc. The editor should support entering raw markup with preview option (same as this discourse forum/GitHub etc.). Saving stores the markup in as in 1) and then renders it as in 2)
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. So far, this middle ground has been markdown shortcuts in the WYSIWYG editor.
The pasting issue is something that has been mentioned a few times now and something that’s on the roadmap. It seems like we need something similar for the handling of CalDAV? The problem here is that HTML can store more information than Markdown. If the user saves a description on the web and then syncs it via CalDAV, information will get lost.
I think I would also have preferred a simpler Markdown editor over the HTML that Vikunja now has, but I can work with it. 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. Fully correct Markdown support may just not be worth it for the project.
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 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
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.
I’m sure we can fix the markdown pasting issue and find a solution for CalDAV as well. I’ll try something and ping here once there’s something usable, but if anyone wants to send a PR, I’d be happy as well.
What exactly does not work, apart from the pasting issue?