To be in the spirit of markdown, you would have to do something like take a csv or table of numbers, and make them into a chart -in a way that you can read in plaintext too.
Plain-text readability is paramount. But additionally, we need to be careful as to how visualizations are implemented. The visual characteristics of the final HTML document are really supposed to exist in the domain of the stylesheet applied to it.
The visualization configuration block in OP's example is perilously close, if not guilty, of violating the traditional separation of concerns we expect with Markdown.
I think visualizations are best left to separate projects that specialize in them - which in turn generate images that can be placed in a Markdown document.
Of course, if anyone finds this useful (obviously the author does) I would never discourage it. I'm simply trying to reconcile this with what I personally believe the main purpose of Markdown to be.
I'm not sure what the benefit of doing it this way is supposed to be.
An inline image, as unnatural as it might appear in a markdown doc (as the DF post notes) is more "readable" in plain-text than what is essentially a block of YAML for configuring a chart in the middle of a document.
This standardization can then result in much improved support for Markdown editors. Think autocomplete for any extended item which works on any Markdown editor.
Maybe basic Markdown (HTML), plus more advanced styling (CSS), and a small scripting language for anything that doesn't cover (JS).
(but I really the idea of using it with Markdown!)
For a system engineer, it's hard to draw visual csv file by java script. markdown is the most simple and convenient tool, it's a good idea to combine markdown with visualization.
