I like the idea of adding visualizations to markdown. I think its got potential. But this implementation is entirely wrong. I could never include it server side or client side because the data source is decoupled. Additionally, the setup reads 10X more like something i'd write for javascript than for markdown.
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.
I'd agree, and this is what I was hinting at in my comment as well.
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.
Interesting, but in a weird way it kind of works against the whole point of Markdown - markup that emphasizes text-only readability.
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.
Right, I'm basically saying the a separate service / utility would generate the image which would, in-turn, be placed in a markdown doc.
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.
Well, that would mean I'd need multiple source files and an ordered way of building the output. The source files would in effect just contain the same information that's here, but split up and away from their context.
I really want to have an extendable Markdown. A standard mechanism for expressing a used extension and providing an implementation for the Markdown processor to apply a transformation.
This standardization can then result in much improved support for Markdown editors. Think autocomplete for any extended item which works on any Markdown editor.
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.
If you're using Emacs and org-mode, look into org-babel which supports R among many other inline languages (C, Haskell, sh, SQL, ....) you can use as if you were in iPython.
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.