I've used mermaid from within markdown before, but the whole premise still leaves me conflicted. The original selling point of markdown is that it wasn't a markup language; it was readable text that could optionally be rendered with some extra niceties if you were reading it in something more sophisticated than a simple text field. While mermaid is undoubtedly useful as a textual language for describing graphs, the spirit of markdown would favor something that actually looked like a graph without needing to run it through a renderer, something more akin to ascii art, but with well-defined semantics such that it would produce something reasonable if you did have a renderer at hand.
While I agree in principle, in practice the result would probably be terrible.
Just look at tables in GFM, which mostly were designed as you propose. They look like tables even before rendering, however the experience of actually creating and editing the tables is not fun at all.
I have a horse in this race (co-founder of a markdown-based note-taking app) and to me, the benefit of markdown is easy + explicit editing, not that it looks the same in plain text vs rendered.
I agree with you on Markdown tables. They're pretty horrendous to write by hand. I wonder if there's an alternative that would be easier? Maybe something that's essentially a CSV embedded in a Markdown file? I'm sure CSV has some edge cases that could be a problem, but it's probably a decent 80/20 (or better) solution if you just want to make a quick table by hand.
CSV are no better than markdown tables to edit by hand. However they’re convenient in that you don’t have to do that and can use a spreadsheet.
rST allows using a csv as a table and that’s mighty convenient. An other thing that’s mighty convenient is rST allows rendering a nested list as a table. It’s not amazing because each list item is a row rather than a column, but it is a lot less confusing than having to edit a markdown table if you’re not in a table-aware editor.
Worth noting that Emacs makes Markdown tables pretty easy to create and format cleanly for plain text viewing, and other editors may/could/should do the same.
I use Sublime almost 100% now-a-days; and, it for sure isn't as nice as Emacs for editing MD tables, but multi-cursor editing does about 80% of the heavy-lifting for MD tables. I guess I could conjecture someone objecting about "really big" tables and editing them ... but, is MD really the right choice in that case?
I personally think the bottom line here is that markdown simply isn't intended nor well suited for anything complex such as tables or diagrams or any such things that have been bolted on afterwards.
Yea, I have to agree. I don't agree with the title. It may be convenient to put Mermaid Gantt diagram SPECIFICATIONS in a Markdown document, but they are not great for displaying the Gantt charts in Markdown.
To me a more accurate title and summary of the article is "TIL: Mermaid Gantt diagram specifications can be embedded and processed in Markdown documents".
You might want to have a look at svgbob or typograms then. I used the former for creating diagrams for a guide on Git and it worked really well. Of course Markdown editors could be better at "drawing" things, which would solve the pain in creating these diagrams.
> (...) the spirit of markdown would favor something that actually looked like a graph without needing to run it through a renderer, something more akin to ascii art, but (...)
I completely disagree. The spirit of Markdown is to provide something that is a user-friendly, simple and easily works on most cases. The spirit of Markdown is not to bear with substandard, unreadable, and outright unfriendly documents just because ineffectiveness and lack of support for basic features is wrongly interpreted as simplicity.
Markdown supports images. Mermaid is nothing more than a way to simplify how developers can put together and maintain images without requiring specialized editors or additional software.
