You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a coordination proposal rather than a request for one large PR. I would like to split the work below into small, independently reviewable changes. I will wait for maintainer feedback before starting the feature parts.
✨ Feature Request
Is your feature request related to a problem? Please describe.
Kan already has useful Markdown support, but the current behaviour is spread across several generations of the editor and a few open issues now overlap or describe behaviour that has since changed.
The current editor is Tiptap rather than a Markdown source editor. It can parse Markdown when content is loaded and, since #498, when plain text is pasted. An edit is then saved as HTML. This works well for the common cases, but it leaves a few different problems under the same “Markdown support” label:
Markdown tables are parsed but lose their structure because the editor schema does not include table nodes;
imported and API-written content may still be raw Markdown, so compatibility with both raw Markdown and stored Tiptap HTML remains important.
We found this while checking a sizeable Trello migration. A large existing comment history still relies on raw Markdown being parsed on read, so replacing that path or blindly rewriting stored content would be risky.
#613 restored Tailwind's existing monospace stack and added a browser regression check without changing the editor or storage format.
2. Make the existing Markdown contract explicit — completed in #614
#614 added focused browser coverage for descriptions, comments, raw Markdown loaded through the API, stored Tiptap HTML, and unsafe links and HTML.
This gives us a factual basis to update or close the now mostly stale #404 and #524 without reimplementing the editor.
3. Preserve Markdown table structure and discuss task lists separately
Tables are the remaining reproducible bug. Markdown parsing already recognises them, but the current editor schema silently flattens their structure. A later edit then saves that flattened result, which makes this a data-preservation problem rather than only a missing formatting feature.
The narrow fix is to register the official Tiptap 2 table nodes, add responsive styling, and cover import, editing, saving, reload, and unsafe links in a browser test. It does not need a table toolbar or a broader table-creation UX.
Task lists remain a separate product choice. My preference is to keep Markdown task items inside the rich text document using Tiptap task-list nodes. Automatically turning pasted Markdown into Kan's native card checklist would change the structure outside the editor and would be difficult to round-trip. An explicit “convert to card checklist” action could be considered later if it is useful.
4. Preserve storage compatibility
The first passes should keep the current boundary: accept both raw Markdown and Tiptap HTML, render both through the same schema, and continue saving editor changes as HTML. No database migration or bulk rewrite is needed. #614 now explicitly covers this compatibility boundary.
If the project later moves from Tiptap 2 and tiptap-markdown to Tiptap 3's official Markdown package, that should be treated as a separate editor-stack migration with import, API, comments and public-card coverage. It is too broad to hide inside one of these fixes.
Describe alternatives you've considered
A Markdown source/preview editor would make the storage format more obvious, but it would replace the established Tiptap, slash-command and bubble-menu UX. That seems disproportionate to the current gaps.
Automatically normalising the existing database to HTML would simplify one code path, but it adds migration risk and makes external Markdown writes harder to reason about. Keeping compatible reads and adding tests is safer.
One PR covering fonts, tests, task lists, tables and a Tiptap upgrade would be hard to review and backport. The pieces above have different risk and product questions, so I would rather keep them independent.
I tested the current main in Chromium. Headings, emphasis, ordinary lists, links, blockquotes, inline code and fenced code blocks work in descriptions and survive reload. Inline formatting and links work in comments. #613 fixed the code font and #614 covers the existing Markdown and security contract. Task markers stay as text, and tables are still flattened on main.
Important
This is a coordination proposal rather than a request for one large PR. I would like to split the work below into small, independently reviewable changes. I will wait for maintainer feedback before starting the feature parts.
✨ Feature Request
Is your feature request related to a problem? Please describe.
Kan already has useful Markdown support, but the current behaviour is spread across several generations of the editor and a few open issues now overlap or describe behaviour that has since changed.
The current editor is Tiptap rather than a Markdown source editor. It can parse Markdown when content is loaded and, since #498, when plain text is pasted. An edit is then saved as HTML. This works well for the common cases, but it leaves a few different problems under the same “Markdown support” label:
code renders in the regular UI font instead of monospace (Code blocks do not render with a monospace font #508);fixed in fix(editor): restore monospace code font #613;basic Markdown now works in comments and card descriptions, while Markdown support in comments #404 and Markdown Support in Cards #524 still suggest that it does not;documented and covered in test(editor): cover markdown behavior and unsafe input #614;[ ]text (Add README-Style Support for All Code Blocks and Markdown Formatting #517);We found this while checking a sizeable Trello migration. A large existing comment history still relies on raw Markdown being parsed on read, so replacing that path or blindly rewriting stored content would be risky.
Describe the solution you'd like
I propose handling this as separate follow-ups.
1.
Fix monospace rendering— completed in #613#613 restored Tailwind's existing monospace stack and added a browser regression check without changing the editor or storage format.
2.
Make the existing Markdown contract explicit— completed in #614#614 added focused browser coverage for descriptions, comments, raw Markdown loaded through the API, stored Tiptap HTML, and unsafe links and HTML.
This gives us a factual basis to update or close the now mostly stale #404 and #524 without reimplementing the editor.
3. Preserve Markdown table structure and discuss task lists separately
Tables are the remaining reproducible bug. Markdown parsing already recognises them, but the current editor schema silently flattens their structure. A later edit then saves that flattened result, which makes this a data-preservation problem rather than only a missing formatting feature.
The narrow fix is to register the official Tiptap 2 table nodes, add responsive styling, and cover import, editing, saving, reload, and unsafe links in a browser test. It does not need a table toolbar or a broader table-creation UX.
Task lists remain a separate product choice. My preference is to keep Markdown task items inside the rich text document using Tiptap task-list nodes. Automatically turning pasted Markdown into Kan's native card checklist would change the structure outside the editor and would be difficult to round-trip. An explicit “convert to card checklist” action could be considered later if it is useful.
4. Preserve storage compatibility
The first passes should keep the current boundary: accept both raw Markdown and Tiptap HTML, render both through the same schema, and continue saving editor changes as HTML. No database migration or bulk rewrite is needed. #614 now explicitly covers this compatibility boundary.
If the project later moves from Tiptap 2 and
tiptap-markdownto Tiptap 3's official Markdown package, that should be treated as a separate editor-stack migration with import, API, comments and public-card coverage. It is too broad to hide inside one of these fixes.Describe alternatives you've considered
A Markdown source/preview editor would make the storage format more obvious, but it would replace the established Tiptap, slash-command and bubble-menu UX. That seems disproportionate to the current gaps.
Automatically normalising the existing database to HTML would simplify one code path, but it adds migration risk and makes external Markdown writes harder to reason about. Keeping compatible reads and adding tests is safer.
One PR covering fonts, tests, task lists, tables and a Tiptap upgrade would be hard to review and backport. The pieces above have different risk and product questions, so I would rather keep them independent.
Additional context
Related work:
tiptap-markdown, partly for Trello imports;I tested the current
mainin Chromium. Headings, emphasis, ordinary lists, links, blockquotes, inline code and fenced code blocks work in descriptions and survive reload. Inline formatting and links work in comments. #613 fixed the code font and #614 covers the existing Markdown and security contract. Task markers stay as text, and tables are still flattened onmain.Implementation ideas (optional)
Keep the monospace fix limited to Tailwind'sCompleted in fix(editor): restore monospace code font #613.fontFamily.monoconfiguration.Put user-visible Markdown behaviour in self-hosted Playwright tests rather than testing implementation details of Tiptap.Completed in test(editor): cover markdown behavior and unsafe input #614 and reused for the table regression.Would you like to work on this feature?