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?
As a prospective user, the lack of support for plaintext is a major sticking point for me. I am however quite sympathetic to the need to provide a WYSIWYG experience.
A comment I made in the Matrix chat that I suspect may have been poorly made/misinterpreted is that I think there’s a way to “have our cake and eat it too” here. Rather, instead of having to maintain two editors for this, it looks like Vikunja could use one editor that supports two modes of operation.
Playing around with their demo, I’m quite impressed by what they’ve put together. Like tiptap, it’s built on prose mirror. However, you can freely switch between the WYSIWYG experience:
[can’t include screenshot due to first-post limits, but give the playground a try!]
In the playground these two editors are shown side by side, but I’d think that a user of Milkdown could easily make it so you can toggle between the two with a pill/switch or similar UI element.
I suspect that there might be a slight mismatch in what I have in mind when talking about one/two editors (sorry!).
I’ve also looked a bit further into Milkdown to be able to better comment on this. The playground that I’m so excited by uses a Dual react componend defined not in the library itself but website/src/components/playground/index.tsx at main · Milkdown/website · GitHub. This uses Milkdown’s Crepe editor synced to a CodeMirror editor — I thought these were more integrated in the library itself, my mistake.
That said, with the particular design of Milkdown/Crepe it does appear that the implementation of the bidirectional syncing in Dual is quite simple/straightforward. It’s been a while since I’ve done much webdev, but it does look it wouldn’t be much work to adapt Dual. The implementation is ~300 loc, and it looks like if you didn’t need live bidirectional updates you wouldn’t need a large chunk of that.
Since I’m now commenting in this thread, I’ll separately mention that another thing that makes me interested in having a plaintext option: the ease of writing integrations with the Vikunja API. For example, actually making tasks editable via a CLI tool like vja. Currently this is read-only because it’s hard to implement an HTML-based editor outside the browser, but this would be much easier if the content was available in a plaintext format.
I don’t want to mix this point with the discussion of the dual editor above, but that Milkdown provides such a smooth WYSIWYG experience while operating on a plaintext representation makes me hopeful that a “best of both worlds” is possible
I’m still doubtful of having to maintain essentially two editors vs one integrated one. I think we’ll serve a broader range of users by having a WYSIWYG editor which has markdown shortcuts and pasting support etc.
It looks like Milkdown is implemented in React? That would mean it’s not possible to integrate into the Vikunja frontend (because that’s implemented in Vue).
We’ll have to find a way to make this work with caldav anyway, it is possible to have something that would work for the api as well.
Another option for vja specifically would be to have it convert the text content to markdown for editing and back to html before sending the update request.
No trouble, thanks for actually giving this idea due consideration. I’m not able to put my hand up for implementing any changes here, so being willing to investigate this further is the least I can do
I get the hesitation around the extra complexity. Given it would be nice to have, I think this is worth consideration if it’s feasible to implement it painlessly. Not being familiar with the Vikunja codebase I of course can’t judge this nearly as well as you, but the simplicity of the react code I linked gives me some hope that it could be done reasonably.
I have noticed this, and checked that Milkdown can be used with Vue. It actually supports a whole range of frontend frameworks; see Vue | Milkdown for the Vue quickstart (it also offers Svelte, Nextjs, and Angular support, to name a few).
Ah, I’m not familiar with CalDev — does that use its own format or something?
This can be done, it’s just impossible to losslessly convert HTML to Markdown, and I’d anticipate a never-ending tail end of bugs/round-trip differences.
It’s a whole separate protocol. Currently, we’re returning html there which does not make sense because most clients only support plaintext. Markdown would help there.
That’s true - how would this be different if switching the editor in the web would be possible?
