CommonMark has yet to implement the popular MultiMarkdown v2+ feature, “Link and Image Attributes.”
Consider the following Markdown:
This is an ![image] link and a regular hypertext [link].
[image]: http://path.to/image "Image title"
[link]: http://path.to/link.html "Some Link"
We’re all pretty familiar with this (it’s part of the original John Gruber spec).
But what if I wanted to apply attributes to the image, like
class="big", I would have to use an
<img> tag instead.
MultiMarkdown allows this:
This is an ![image] link and a regular hypertext [link], with attributes.
[image]: http://path.to/image "Image title" width=100% class=big style="border: solid black 1px;"
[link]: http://path.to/link.html "Some Link" class=external
So we could use basically the same syntax that we’re used to for reference image links and hypertext links
Nobody likes named attributes in markdown, although some generic syntax is being proposed (mostly by people with a strong coding background) on a regular basis. Special alternatives for image dimensions have already been discussed. If they were deemed useful, classes and IDs in reference link definitions and code block info strings would probably be preceded by dot
. and hash sign
[image]: <http://path.to/image> "Image title" =100%* .big
That seems acceptable. But it also seems like obfuscation just for obfuscation’s sake. In other words, why use
class="" is easier to understand without pouring over the spec?
Conceptually it’s not difficult to equate
#big as the same thing as
id="big", but it does add an extra level of complexity.
That’s why the MMD implementation is nice:
width=100px (admittedly, I wish they would just do
You are assuming HTML output and knowledge here, when you should assume neither.
I hope you don’t think I’m being argumentative, but I don’t think anyone could use Markdown without some basic HTML knowledge. Yes, Markdown is designed to be a markup language for HTML. Yes, it is designed to be more inherently readable than HTML.
But suggesting that a Markdown (CommonMark) user requires no prior/previous/“assumed” HTML knowledge is like saying an ALMS GT3 driver requires no knowledge of driving a road car on the road.
No, I don’t think so. I think it’s intended to be a format that starts as plain text, may never leave that format, or may jump straight to PDF, LaTeX, RTF or another non-HTML format. HTML support is important for advanced usage, but CommonMark should probably avoid HTML-centric assumptions and focus on the content, with minimal style distractions. That’s what formats like AsciiDoc are for.
If class support is added, the leading dot notation matches the CSS selector, leaving fewer syntax alternatives to remember, though classes feel like excessive styling.