elk-zone / elk

A nimble Mastodon web client
https://elk.zone
MIT License
5.38k stars 554 forks source link

Unwanted markdown interpretation in posts #1877

Open zaidhaan opened 1 year ago

zaidhaan commented 1 year ago

Issue

Some posts, such as one from #401 which points to this post happens to contain text consisting of asterisks that can be interpreted as markdown (but is not intended to be), and so that's done when viewed using elk.

We should be able to make posts like this, without having markdown formatting applied to them: image

This would help address cases where markdown characters like asterisks are unintentionally rendered as markdown text. One realistic example of this would be the German gender star or perhaps even c*nsored w*rds.

Technical and design considerations

From a technical perspective, it should be possible to support markdown and plaintext (send raw messages like *this* if plaintext is used, else HTML-encoded messages like <em>this</em> if not; inverse applied on the receiving end)

From a design perspective, we would need to consider how to support all these features together without being overwhelming/confusing.

Potential solutions

Solution 1. Plaintext editor; two modes: Plaintext and Markdown (with Preview)

One solution to the issue of unwanted markdown interpretation would be to support two modes: plaintext and markdown. And within markdown mode, a preview is made available. Think of it like this:

Furthermore, within markdown mode, if we wish to include "plaintext" characters, they could be inserted as backslash-escaped characters. In fact, this is what GitHub does as demonstrated below:

Write tab (this would be the markdown editor for elk) image Preview tab image

Solution 2. Backslash escaping support in current editor

Instead of introducing a new feature (= more confusing / overwhelming), we can simply implement the backslash escaping described above and support plaintext through escaping.

One drawback to this would be if you use "plain" markdown characters frequently you will have to escape them manually like \*this\* which might be annoying for users.

stackblitz[bot] commented 1 year ago

Solve in StackBlitz Codeflow Start a new pull request in StackBlitz Codeflow.

patak-dev commented 1 year ago

I think we can't use Solution 2, the whole idea is that we are able to render markdown in the client because when the post isn't rendered in other clients, it is still not bothersome. Seeing something like *italic* is fine. \*this\* will look ok in Elk but not in other clients.

It is hard to have a good solution here. Maybe we should restrict our markdown parsing to avoid issues with the German gender star or c*nsored w*rds. We could for example only allow for italic and bold that are wrapping full words: this *works* and this w*nt*.

We should also have a way for users to opt out of rendering markdown in the client, as a global preference, and maybe on each post?

zaidhaan commented 1 year ago

Seeing something like *italic* is fine. \*this\* will look ok in Elk but not in other clients.

Whoops, I completely forgot that italics and bold text from tiptap aren't transmitted as <strong>s and <em>s but rather they are converted from those and sent as markdown text like *italic* and **bold**. So you're right, it would be impossible to tell whether a status of <p>plain *italic*</p> should be interpreted as plain text or markdown.

It is hard to have a good solution here.

Agreed. Hmm... I was just reminded of mastodon/mastodon#23913 and I wonder whether that's going to make things easier for elk. I haven't looked at the PR closely so I don't really know the implications of it, but I suppose one solution might be to wait for the next mastodon release that supports richtext/markdown which might address this issue somehow.

We should also have a way for users to opt out of rendering markdown in the client, as a global preference, and maybe on each post?

Yeah, I think opting out of rendering markdown would be a good option to have. For specific posts though, hmm I hadn't thought about that, but that does sound interesting.

Let's see what others have to say. I guess this issue will take a bit of time and further discussion before it can be fully resolved.

johnsonm commented 1 year ago

I see a lot of technical posts where the client-side markdown rendering makes the post useless, and all I can do is load the original page for the post, or go back to the standard UI.

Most of the fediverse software out there actually supports rich text, and even for Mastodon those who really want it use glitch, which renders it server side.

Trying to make up in the client for this steadfast refusal in upstream Mastodon will just keep creating this difficulty.

I would complain less if I could simply disable client-side markdown interpretation, and honor only rich text that is server rendered.

I don't know whether that would also solve the really annoying problem of not rendering quotes distinctly. Elk just eats and hides leading > characters. See #1502

Shinigami92 commented 1 year ago

One more reason for me pushing people to use : instead of * as german gender delimiter 🙃