vikunja/vikunja
Archived
8
54
Fork 94
Code Issues 101 Pull Requests 31 Packages Releases 37 Activity

Render markdown in title #1801

New Issue
Open
opened 2021-07-08 10:00:55 +00:00 by bolgrov · 13 comments
bolgrov commented 2021-07-08 10:00:55 +00:00
Copy Link

Vikunja has markdown support for comments, however it does not currently support it for Tasks titles.
It would be beneficial to support this not only for aesthetic purposes but more importantly for better usability.
I tend to use a lot of links in the Tasks titles: [site](link) and in Todoist this renders a clickable site but in Vikunja it just shows the unrendered markdown.

Thank you !

Vikunja has markdown support for comments, however it does not currently support it for Tasks titles. It would be beneficial to support this not only for aesthetic purposes but more importantly for better usability. I tend to use a lot of links in the Tasks titles: ` [site](link)` and in Todoist this renders a clickable `site` but in Vikunja it just shows the unrendered markdown. Thank you !
👍 1
konrad added the
kind/feature
 label 2021-07-09 15:54:37 +00:00
konrad commented 2021-07-09 15:56:50 +00:00
Owner
Copy Link

I can see how this would be useful, but would this really be faster than putting the link in a comment or the task description?

I can see how this would be useful, but would this really be faster than putting the link in a comment or the task description?
jln commented 2021-10-13 07:14:33 +00:00
Copy Link

Hi,

I totally agree with bolgrov, I think it's really faster to click on a link in title, than to look for this link in comments.

Moreover, markdown support in comments would allow to use bold and italic, thus to improve readibility of some important information.

Hi, I totally agree with bolgrov, I think it's really faster to click on a link in title, than to look for this link in comments. Moreover, markdown support in comments would allow to use bold and italic, thus to improve readibility of some important information.
dpschen commented 2021-10-13 09:19:17 +00:00
Member
Copy Link

I would love to have the option to use markdown links in a task title.

Moreover, markdown support in comments would allow to use bold and italic, thus to improve readibility of some important information.

Isn't markdown already supported in comments?

I would argue that using markdown to format bold and italic might leed to some problems because it decreases options our options to show other meta information next to the task in a list. What I mean by that is e.g. if you allow italic inside the task title then it's harder to see the due date, since it's currently italic as well (see attachment). Also default markdown syntax supports normal HTML which we probably don't want in titles.

Because of that I think it makes sense to create an allowlist of what syntax is supported. Currently I think that would only include markdown links. We don't want to have animated graphics in task titles

Maybe this could also be implemented in stages:

  • support only markdown urls in titles

cherry on top:

Related with all of that is the discussion reagarding the implementation of a new editor

I would love to have the option to use markdown links in a task title. > Moreover, markdown support in comments would allow to use bold and italic, thus to improve readibility of some important information. Isn't markdown already supported in comments? I would argue that using markdown to format bold and italic might leed to some problems because it decreases options our options to show other meta information next to the task in a list. What I mean by that is e.g. if you allow italic inside the task title then it's harder to see the due date, since it's currently italic as well (see attachment). Also default markdown syntax [supports normal HTML](https://daringfireball.net/projects/markdown/syntax#html) which we probably don't want in titles. Because of that I think it makes sense to create an allowlist of what syntax is supported. Currently I think that would _only_ include markdown links. We don't want to have [animated graphics](https://github.com/sindresorhus/css-in-readme-like-wat) in task titles Maybe this could also be implemented in stages: - support _only_ markdown urls in titles cherry on top: - add [api for automatic title fetching](https://kolaente.dev/vikunja/api/issues/913) - create link by pasting url over marked text --- Related with all of that is the [discussion reagarding the implementation of a new editor](https://kolaente.dev/vikunja/frontend/issues/781)
Screenshot 2021-10-13 at 11.01.14.png
11 KiB
Screenshot 2021-10-13 at 11.01.14.png
jln commented 2021-10-13 09:45:08 +00:00
Copy Link

Isn't markdown already supported in comments?

There are but from my point of view, it's a huge gain in fluidity to avoid opening and reading the comments again and again, and be able to read important information in task title itself.

I would argue that using markdown to format bold and italic might leed to some problems because it decreases options our options to show other meta information next to the task in a list. What I mean by that is e.g. if you allow italic inside the task title then it's harder to see the due date, since it's currently italic as well (see attachment).

I understand. For me, it is the user's responsibility to use formatting wisely. If the user is bothered by the fact that his italicized text is confused with the due date, it is up to him not to use italics at the end of the title. But this should not prevent the use of italics elsewhere in the title.

(This is the choice made by other tools like Quire.io for example. The latter allows you to use links, italic, bold, and even css to modify the text color, the text size, the background color… in task title)

> Isn't markdown already supported in comments? There are but from my point of view, it's a huge gain in fluidity to avoid opening and reading the comments again and again, and be able to read important information in task title itself. > I would argue that using markdown to format bold and italic might leed to some problems because it decreases options our options to show other meta information next to the task in a list. What I mean by that is e.g. if you allow italic inside the task title then it's harder to see the due date, since it's currently italic as well (see attachment). I understand. For me, it is the user's responsibility to use formatting wisely. If the user is bothered by the fact that his italicized text is confused with the due date, it is up to him not to use italics at the end of the title. But this should not prevent the use of italics elsewhere in the title. (This is the choice made by other tools like Quire.io for example. The latter allows you to use links, italic, bold, and even css to modify the text color, the text size, the background color… in task title)
dpschen commented 2021-10-13 09:55:36 +00:00
Member
Copy Link

There are but from my point of view, it's a huge gain in fluidity to avoid opening and reading the comments again and again, and be able to read important information in task title itself.

I think the magnitude of that issue might be reduced if we find a way to show tasks non blocking (not as a popup) in a good way.

What also comes to my mind is something recently introduces in todoist: they show the first line of the description cut of after some characters. See the two attached images:

  1. task in normal list after added
  2. task in detail view

What I think is noteworthy is that they decided to remove line breaks in the preview. Not sure if I like that 🤷‍♂️

@jln What do you think? :)

> There are but from my point of view, it's a huge gain in fluidity to avoid opening and reading the comments again and again, and be able to read important information in task title itself. I think the magnitude of that issue might be reduced if we find a way to show tasks non blocking (not as a popup) in a good way. What also comes to my mind is something recently introduces in todoist: they show the first line of the description cut of after some characters. See the two attached images: 1) task in normal list after added 2) task in detail view What I think is noteworthy is that they decided to remove line breaks in the preview. Not sure if I like that 🤷‍♂️ @jln What do you think? :)
konrad commented 2021-10-13 11:01:59 +00:00
Owner
Copy Link

I think we could do this with an allowlist to allow only the usual formatting and links, no images or anything else. Then it would be up to the user if they want to do all kinds of confusing formatting with it.

Implementation-wise we'll also have to sanitze the input before rendering, not sure about the effect this has on the total bundle size.

I think we could do this with an allowlist to allow only the usual formatting and links, no images or anything else. Then it would be up to the user if they want to do all kinds of confusing formatting with it. Implementation-wise we'll also have to sanitze the input before rendering, not sure about the effect this has on the total bundle size.
jln commented 2021-10-16 15:11:58 +00:00
Copy Link

I don't know todoist very well. I am more familiar with Quire.io which provides, in my opinion, the best UX I have ever used.

Here is a very short capture that shows the fluidity of the tool. A due date or a tag can be applied in 2 clicks, without opening any popup or new window. Access to a more feature-rich panel is done via a click, or a simple press on the space bar. This panel can be pinned if needed.

Finally, to come back to Markdown which is the subject of this issue (sorry for the off-topic!), it can be applied when creating the task or when editing it (editing takes only one click!)

I don't know todoist very well. I am more familiar with Quire.io which provides, in my opinion, the best UX I have ever used. Here is a very short capture that shows the fluidity of the tool. A due date or a tag can be applied in 2 clicks, without opening any popup or new window. Access to a more feature-rich panel is done via a click, or a simple press on the space bar. This panel can be pinned if needed. Finally, to come back to Markdown which is the subject of this issue (sorry for the off-topic!), it can be applied when creating the task or when editing it (editing takes only one click!)
quire.gif
585 KiB
quire.gif
dpschen commented 2021-10-16 15:19:11 +00:00
Member
Copy Link

Thanks for the video :) really interesting to see.

I like the pinnable sidepanel a lot :)

What I don't get from the video:
How do you open the sidepanel vs edit the text?
Do you have to click on the text vs somewhere else in the line?

Thanks for the video :) really interesting to see. I like the pinnable sidepanel a lot :) What I don't get from the video: How do you open the sidepanel vs edit the text? Do you have to click on the text vs somewhere else in the line?
jln commented 2021-10-16 16:13:28 +00:00
Copy Link

The first time, I opened the sidepanel by pressing the space key, then I opened it by clicking the icon.

To edit task title, I double-clicked it.

The first time, I opened the sidepanel by pressing the space key, then I opened it by clicking the icon. To edit task title, I double-clicked it.
👍 1
jln commented 2021-10-16 17:47:01 +00:00
Copy Link

In fact, you can also open the panel by clicking on a blank space of the task (on the right of the title itself).

I've recorded a more complete screenshot showing how it's possible to create and edit task without leaving the main tasks list.

In fact, you can also open the panel by clicking on a blank space of the task (on the right of the title itself). I've recorded a more complete screenshot showing how it's possible to create and edit task without leaving the main tasks list.
quire2.gif
2.6 MiB
quire2.gif
DanielPantle commented 2024-10-02 10:17:12 +00:00
Contributor
Copy Link

Links in the title are one of the features I miss the most coming from Todoist. I would really love seeing this implemented!

I think the discussion in this issue drifted away a bit from the actual topic, I guess those other user interface improvements (side panel, quick editing, etc.) can be discussed elsewhere :)

I would be willing to contribute to this, but I am not very familiar with the vikunja development yet. I have a few questions:

  • before I start digging into it, is it realistic that this feature will be merged when completed or are there any solid considerations against it?
  • @konrad you mention that an allowlist could be used to only support parts of markdown (like links, formatting, etc.). Is this already done somwhere in this project (so I could take it as a template)?
  • same question regarding sanitization of the input: is this already done for e.g. comments?
  • can somebody give me some hints what would need to be changed for it? Especially if api changes are necessary (e.g. data type of title models/tasks.go or only the frontend
Links in the title are one of the features I miss the most coming from Todoist. I would really love seeing this implemented! I think the discussion in this issue drifted away a bit from the actual topic, I guess those other user interface improvements (side panel, quick editing, etc.) can be discussed elsewhere :) I would be willing to contribute to this, but I am not very familiar with the vikunja development yet. I have a few questions: - before I start digging into it, is it realistic that this feature will be merged when completed or are there any solid considerations against it? - @konrad you mention that an allowlist could be used to only support parts of markdown (like links, formatting, etc.). Is this already done somwhere in this project (so I could take it as a template)? - same question regarding sanitization of the input: is this already done for e.g. comments? - can somebody give me some hints what would need to be changed for it? Especially if api changes are necessary (e.g. data type of title [models/tasks.go](https://kolaente.dev/vikunja/vikunja/src/commit/358661e060a07bf915d11d48fcdad8eb45496046/pkg/models/tasks.go) or only the frontend
konrad commented 2024-10-02 16:18:18 +00:00
Owner
Copy Link

before I start digging into it, is it realistic that this feature will be merged when completed or are there any solid considerations against it?

I don't think there's anything against merging this. It is not as easy to get right though as there are a few considerations regarding a11y (what do you focus when navigating the task list with the keyboard?) and editing the title (should we keep the inline edit? If we do that, how do we make sure clicking on the title works?) but those are not unsolvable problems.

How does Todoist solve these potential problems?

you mention that an allowlist could be used to only support parts of markdown (like links, formatting, etc.). Is this already done somwhere in this project (so I could take it as a template)?

We should definitely do this, but haven't done it yet.

same question regarding sanitization of the input: is this already done for e.g. comments?

IIRC the editor uses DomPurify to handle this.

can somebody give me some hints what would need to be changed for it? Especially if api changes are necessary (e.g. data type of title models/tasks.go or only the frontend

As I see it, this affects only the frontend. The question is though if we should use markdown or html, given that the description and comments use html and using it everywhere would be consistent. But editing markdown is way faster for things like links and simple formatting. Pinging @dpschen do you have opinions here?

> before I start digging into it, is it realistic that this feature will be merged when completed or are there any solid considerations against it? I don't think there's anything against merging this. It is not as easy to get right though as there are a few considerations regarding a11y (what do you focus when navigating the task list with the keyboard?) and editing the title (should we keep the inline edit? If we do that, how do we make sure clicking on the title works?) but those are not unsolvable problems. How does Todoist solve these potential problems? > you mention that an allowlist could be used to only support parts of markdown (like links, formatting, etc.). Is this already done somwhere in this project (so I could take it as a template)? We should definitely do this, but haven't done it yet. > same question regarding sanitization of the input: is this already done for e.g. comments? IIRC the editor uses DomPurify to handle this. > can somebody give me some hints what would need to be changed for it? Especially if api changes are necessary (e.g. data type of title models/tasks.go or only the frontend As I see it, this affects only the frontend. The question is though if we should use markdown or html, given that the description and comments use html and using it everywhere would be consistent. But editing markdown is way faster for things like links and simple formatting. Pinging @dpschen do you have opinions here?
frederick added the
moved-to-github
 label 2025-04-01 11:07:30 +00:00
frederick commented 2025-04-01 11:07:30 +00:00
Member
Copy Link

As we're moving Vikunja to GitHub, this issue has been migrated to GitHub: https://github.com/go-vikunja/vikunja/issues/488

To learn more about why we're doing this, please check out the announcement.

As we're moving Vikunja to GitHub, this issue has been migrated to GitHub: https://github.com/go-vikunja/vikunja/issues/488 To learn more about why we're doing this, please check out the [announcement](https://vikunja.io/changelog/moving-to-github/).
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
dependencies
duplicate
This issue or pull request already exists
help wanted
Need some help
invalid
Something is wrong
kind/bug
Something is not working
kind/feature
New feature
moved-to-github
needs reproduction
question
More information is needed
security
wontfix
This won't be fixed
No Label
moved-to-github
Milestone
No items
No Milestone
Assignees
Clear assignees
dpschen frederick konrad renovate shilch
No Assignees
6 Participants
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vikunja/vikunja#1801
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?