Show HN: MDV – a Markdown superset for docs, dashboards, and slides with data
Posted by drasim 2 days ago
Comments
Comment by kevinkoning 2 days ago
I love the idea of extending markdown to include more visual elements, but if you're not careful you just reinvent HTML.
Here's my personal take on extending table syntax for charts. Easy to write, and if a renderer/parser understands the syntax you get a beautiful chart, and if it doesn't you get a table with slightly weird headings:
| Month::x | Revenue::y1 | Cost::y2 |
| -------- | ----------: | -------: |
| Jan | $82,000 | $51,000 |
| Feb | $91,000 | $56,000 |
| Mar | $95,000 | $58,000 |Comment by rao-v 2 days ago
Which is all to say I really like the table proposal here - adding an optional linter to make the data look tabular in unrendered markdown will make it even better
Comment by freedomben 2 days ago
This is one of those moments where I realize that the vim life spoils me. It's so easy to do this in vim that I don't even think about. I probably use it a dozen times per day such as commenting out code.
Ctrl + v, select where you want the character, then hit I (shift + i), type your thing, hit escape, and Bob's your uncle.
Comment by jez 2 days ago
https://docutils.sourceforge.io/docs/ref/rst/directives.html...
Where a table is specified as a depth-2 list and then post processed into a table. Lists support the full range of block elements already: you can have multiple paragraphs, code blocks, more lists, etc. inside a list item.
This syntax inspired the author of Markdoc[1] (who came from an rST background) to support tables using `<hr>`-separated lists[2] instead of nested lists (to provide more visual separation between rows).
I have found various implementations of list table filters for Pandoc markdown[3][4], but have never gotten around to using any of them (and I've tossed around ideas of implementing my own).
[2] https://markdoc.dev/docs/tags#table
Comment by toastal 2 days ago
Comment by nine_k 2 days ago
Comment by thunderbong 2 days ago
Comment by cush 2 days ago
Comment by franga2000 2 days ago
I have documents with essentialy zero direct styling, just paragraph styles (for headings, bullets, code blocks, quotes) and character styles (links, inline code). The UI isn't super well optimized for that, but once you get used to it, it's so much nicer than Markdown or LaTeX for multi-page print work.
Comment by esafak 2 days ago
Comment by microflash 2 days ago
Comment by nzoschke 2 days ago
I continue to love Markdown and always push it a bit further than Commonmark, with frontmatter, schemas, code fence metadata too.
I've been enjoying https://djot.net/ as a superset of Markdown that is feels very well designed and extensible too.
You may look into its syntax and tooling for prior art or some extra lift.
I'm trying to get a djot extension in Zed for syntax highlighting if anyone minds adding a to help signal some community interest.
Comment by amcaskill 2 days ago
We moved to stripe's Markdoc variant for the component syntax last year and have been really happy with it. Models are good at writing it, people are good at reviewing it.
Here's an area chart that would issue a SQL query for weekly revenue totals:
``` {% area_chart data="my_table" x="date" y="sum(revenue)" date_grain="week" /%} ```
Comment by tnolet 2 days ago
Comment by Diti 2 days ago
Comment by mbreese 2 days ago
At least, that would’ve my rationale.
Comment by ricardobeat 1 day ago
The profile seems to be a real person, CEO/CTO level of a small/medium company, but with zero history of OSS contributions, publishing anything or social media presence. It's the third project of this kind to show up in HN this week.
Comment by drasim 1 day ago
Comment by FailMore 2 days ago
This problem has risen to the top of many people’s minds at this moment (including mine!). My Show HN for a similar cli + web based solution (https://sdocs.dev) is on the /show page now (https://news.ycombinator.com/item?id=47777633).
I also went with Front Matter for styling and added an interactive styling mode you can do on the web to test it out immediately. There are some examples on my homepage which demonstrate it in action.
SDocs is cli -> instantly rendered on web
Despite being in the browser, the content of SDocs rendered Markdown files remain local to you. SDoc urls contain your markdown document's content in compressed base64 in the url fragment (the bit after the `#`): https://sdocs.dev/#md=GzcFAMT...(this is the contents of your document)... The url fragment is never sent to the server (see https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...: "The fragment is not sent to the server when the URI is requested; it is processed by the client").
The sdocs.dev webapp is purely a client side decoding and rendering engine for the content stored in the url fragment.
This also means you can share your .md files privately by sharing the url.
Also, I’m sorry I high jacked your post to some degree with this comment. It’s just a little too relevant for me not to leave a comment!
Comment by remywang 2 days ago
> .mdv is strict CommonMark plus four additions:
> YAML front-matter for title, theme, named styles, and dataset references.
> Fenced blocks for data/visuals: ```chart type=bar x=region y=sales.
> ::: containers for styled regions and layout: ::: callout / ::: columns.
> ::: toc for an auto-generated table of contents.
Comment by jonmoore 1 day ago
Comment by sieste 2 days ago
Comment by bthallplz 2 days ago
Comment by FailMore 2 days ago
Comment by garyfirestorm 2 days ago
Comment by aitchnyu 13 hours ago
There are tools to edit PPTs and movies with React.
https://wyozi.github.io/react-pptx/ https://www.remotion.dev/
Comment by chelm 2 days ago
https://wire.wise-relations.com/guides/components/
my takeaway:
- add lint or errors, otherwise your formatting will break, e.g. LLMs and humans will add text too long or too short and your design system will not be able to handle this.
- it's great for low token input
- validate the layout of the user vs. the components used.
- seen here before: https://myst-parser.readthedocs.io/en/latest/syntax/optional...
Comment by drasim 2 days ago
Comment by ivan_gammel 2 days ago
Comment by phyzix5761 2 days ago
Comment by arikrahman 2 days ago
Comment by maleldil 2 days ago
Comment by AlecSchueler 2 days ago
Comment by vishal_ch 1 day ago
Comment by drasim 21 hours ago
Comment by ifh-hn 2 days ago
Comment by realrocker 2 days ago
Comment by pixelmonkey 2 days ago
Best for slides that are just bullet points, full-slide images, and code. Especially code. Less good if you have a lot of images or need to do your own styles or layout.
Comment by woodydesign 2 days ago
I’m a product designer, and I could totally see this fitting into my workflow for design briefs, strategy, review, and crit docs. Markdown is too simple, and Figma is too visual. This feels like a great middle ground.
Comment by dhruv3006 2 days ago
PS : Even I built an API tool on markdown - https://voiden.md.
Comment by 0xbadcafebee 2 days ago
Comment by phrotoma 1 day ago
Comment by simonkagedal 1 day ago
And in the best of worlds, that file format is simple enough to be understood in code reviews and scenarios where you want to generate them programmatically, not a huge incomprehensible json or xml.
I find this to be only even more important in 2026 where you could then also let a code agent generate the dashboard (any agent, any dashboarding software – no need for bespoke agent embeddings in the dashboard UI).
The mouse clickers can click their mouses and those of us (humans and machines) who prefers working with text files can do that. A good file format should take both into account.
Comment by gkfasdfasdf 2 days ago
Comment by FailMore 2 days ago
Comment by gkfasdfasdf 2 days ago
Comment by RoxiHaidi 1 day ago
Comment by daylab 2 days ago
Comment by zbyforgotp 2 days ago
Comment by zephyrwhimsy 2 days ago
Comment by johnwhitman 2 days ago