Consistent attribute syntax


Just my 2pc on the concrete syntax: I would prefer

quote : mb21, post : 5, topic : 272

(with the spaces around : and after , probably optional) over

quote = mb21 post = 5 topic = 271

with or without spaces, for two reasons:

  1. It looks nicer (you can’t discuss about that, can you :wink:

  2. The “:” is easier to type than “=”, both on an US keyboard, and on the DE layout too (and I guess the same holds true for other layouts, because “:” is used more often than “=”). But then again, typing “{}” on a DE keyboard layout is a PITA already…


I agree, @tin-pot, that aesthetics matter. Markdown isn’t HTML; a focus on readability is paramount. I wouldn’t require the spaces either, as this syntax feels natural:

quote: mb21, post: 5, topic: 272

But as an option, adding a space after each key looks fine as well:

quote : mb21, post : 5, topic : 272


Let’s refine that just a bit:

  1. key: value pairs only (no id/class shorthands)
  2. : must be followed by at least one space
  3. unquoted # and = are not allowed

We now have a seemingly complete Inline YAML metadata extension proposal, which is accidentally compatible with the proposal that is the subject of this topic.


The draft proposal is very good, strongly defined and highly-compatible :relaxed:

I do have a couple of reservations, however, that I’d like to voice. I realize I’m slightly late to this party, but I didn’t see those raised above.

  1. Custom spans are an integral part of the Attributes extension, which means an implementation claiming compliance with the extension MUST support these. I believe they belong in a separate extension (perhaps one that is dependent on the Attributes extension).

  2. I find the spacing requirements inconsistent (and, in the case of list items, overly restrictive):

    • Inlines: no leading space.

      So far, so good.

    • Thematic breaks, headings, fenced code blocks and reference links: one or more leading spaces.

      Consistent with neither inlines nor fenced code class declarations.

    • List items: exactly as many leading spaces as the list markers.

      Is this a remnant from an old spec version that posed a similar restriction on list continuation?

I apologize in advance if any of these had been discussed.


How about adding indented code blocks? There seems to be a use case for that as well.


Totally voting this UP! I like the Markdown Extra way. Creating anchors and resizing images is essential. Being a Russian writer it is also very useful to set custom (non-auto-generated) ids to cope with any Unicode troubles while converting to HTML or LaTeX.

As for those who are afraid of HTMLness and “techyness”, you are not obliged to use those. To say even more, the fact that embedded images are not being visible in the text editor is already not so user-friendly or readable.


I totally agree with the suggested spec already.

For completeness, here another (important) use case - open links (e.g. PDFs) in a separate window:
<a href="" target="_blank">Hello, world!</a>

This could be a sample implementing that target attribute:
[link]: "Some Link" target="_blank"


Consistent attribute syntax is not on the list of issues to resolve before CommonMark 1.0, so I’ve moved this topic over to “Extensions”.


@mb21 did anything happen with your pull request? I hate replying to a message that’s more than 2 years old.

I just wanted to point out my preference for being able to add an attribute to a list item via the inline syntax, which I see your pull request for the spec doesn’t include


- hello {id=1}

rather than

- hello


I think this should rather be a conversation on adding meta attributes to markdown than all of this focus on html attributes


I think for todo lists, GitHub task list items are visually and intuitively cleaner solution.

* [ ] open (undone) task item
* [x] closed (done) task item
* [X] closed (done) task item

To change done/undone status only requires changing one character and in all cases the markdown source tends to reflect the fact that it is a task item.

In my implementation I made GitHub task items an optional extension, rendered as:

Without it these render as:

Which still conveys them as task items.


There’s a topic discussing their implementation as a seperate CommonMark extension.


Has anyone thought about how this would apply to tables? E.g. In psv, I’ve been thinking about how would I add self validating tables, e.g. a simple form of a table schema.

Would I still have to wrap a json payload in quote? Or would json be recognised as a value payload? Or is there a better way? Or is this beyond the scope?

{#tableID schema={"First Header": "string", "Second Header": "string" } }
| First Header  | Second Header |
| ------------- | ------------- |
| Content Cell  | Content Cell  |
| Content Cell  | Content Cell  |