# Spec

**URL:** https://talk.commonmark.org/c/spec/6.md

[Latest](https://talk.commonmark.org/latest.md) · [Categories](https://talk.commonmark.org/categories.md) · [Tags](https://talk.commonmark.org/tags.md)

---

## [What changed in CommonMark?](https://talk.commonmark.org/t/what-changed-in-commonmark/15)

<div class="topic-metadata">

**Author:** [@codinghorror](https://talk.commonmark.org/u/codinghorror)\
**Replies:** 16\
**Last updated:** [November 20, 2020, 12:14am UTC](https://talk.commonmark.org/t/what-changed-in-commonmark/15 "2020-11-20T00:14:11Z")

</div>

In general, as little as possible! The goal of CommonMark is not to redefine what Markdown is, or change the syntax, but make it parseable and predictable. We did try to address some minor persistent Markdown complaint…

---

## [About the Spec category](https://talk.commonmark.org/t/about-the-spec-category/119)

<div class="topic-metadata">

**Author:** [@riking](https://talk.commonmark.org/u/riking)\
**Replies:** 0

</div>

Discussion about the CommonMark spec proper. Use this category for bug reports/change requests.

---

## [Should fenced code blocks always remain visible as source?](https://talk.commonmark.org/t/should-fenced-code-blocks-always-remain-visible-as-source/9156)

<div class="topic-metadata">

**Author:** [@andrewvelez](https://talk.commonmark.org/u/andrewvelez)\
**Replies:** 1\
**Last updated:** [October 3, 2026, 7:14pm UTC](https://talk.commonmark.org/t/should-fenced-code-blocks-always-remain-visible-as-source/9156 "2026-10-03T19:14:18Z")

</div>

I started thinking about this after trying to save a Mermaid diagram from a GitHub README as an image. The diagram was written inside a fenced code block, but GitHub had replaced the source with the rendered diagram. Th…

---

## [Image tag should expand to figure when used with title](https://talk.commonmark.org/t/image-tag-should-expand-to-figure-when-used-with-title/265)

<div class="topic-metadata">

**Author:** [@halfdan](https://talk.commonmark.org/u/halfdan)\
**Replies:** 12\
**Last updated:** [September 10, 2026, 5:40pm UTC](https://talk.commonmark.org/t/image-tag-should-expand-to-figure-when-used-with-title/265 "2026-09-10T17:40:35Z")

</div>

With the syntax for images supporting titles in http://jgm.github.io/stmd/spec.html#images it would be great if the image tag would expand to a figure with caption like: !\[alt text\](/url "my caption") \<figure\> \<im…

---

## [A list of common mistakes that people make while writing Markdown](https://talk.commonmark.org/t/a-list-of-common-mistakes-that-people-make-while-writing-markdown/9120)

<div class="topic-metadata">

**Author:** [@notriddle](https://talk.commonmark.org/u/notriddle)\
**Replies:** 0\
**Last updated:** [August 20, 2026, 11:45pm UTC](https://talk.commonmark.org/t/a-list-of-common-mistakes-that-people-make-while-writing-markdown/9120 "2026-08-20T23:45:15Z")

</div>

Continuing the discussion from Djot: A light markup language by @jgm, knowingly acting out xkcd 386 “Duty Calls”: I think the members of this forum spend too much time talking about power-user features like ease-of-impl…

---

## [Djot: A light markup language by @jgm](https://talk.commonmark.org/t/djot-a-light-markup-language-by-jgm/4229)

<div class="topic-metadata">

**Author:** [@vas](https://talk.commonmark.org/u/vas)\
**Replies:** 22\
**Last updated:** [August 19, 2026, 12:07pm UTC](https://talk.commonmark.org/t/djot-a-light-markup-language-by-jgm/4229 "2026-08-19T12:07:51Z")

</div>

Continuing the discussion from Beyond Markdown because I think @jgm’s jdot deserves its own forum topic. Link to a Playground created by @dtinth: https://djot-playground-poc.vercel.app

---

## [Beyond Markdown](https://talk.commonmark.org/t/beyond-markdown/2787)

<div class="topic-metadata">

**Author:** [@jgm](https://talk.commonmark.org/u/jgm)\
**Replies:** 63\
**Last updated:** [August 19, 2026, 11:22am UTC](https://talk.commonmark.org/t/beyond-markdown/2787 "2026-08-19T11:22:28Z")

</div>

Beyond Markdown In developing Commonmark, we have tried, as far as possible, to remain faithful to John Gruber’s original Markdown syntax description. We have diverged from it only occasionally, in the interest of removi…

---

## [Would a streaming guidance for CommonMark be useful?](https://talk.commonmark.org/t/would-a-streaming-guidance-for-commonmark-be-useful/9115)

<div class="topic-metadata">

**Author:** [@cjccjj](https://talk.commonmark.org/u/cjccjj)\
**Replies:** 0\
**Last updated:** [August 18, 2026, 7:20am UTC](https://talk.commonmark.org/t/would-a-streaming-guidance-for-commonmark-be-useful/9115 "2026-08-18T07:20:16Z")

</div>

As Markdown increasingly arrives live as a stream in chat apps, terminals, coding agents, and other interfaces, full-document Markdown parsing has become a performance bottleneck, causing CPU spikes and UI lag. Many UIs …

---

## [Illegal HTML from Autolinks in Link Text](https://talk.commonmark.org/t/illegal-html-from-autolinks-in-link-text/9092)

<div class="topic-metadata">

**Author:** [@pugmire](https://talk.commonmark.org/u/pugmire)\
**Replies:** 3\
**Last updated:** [July 28, 2026, 1:15pm UTC](https://talk.commonmark.org/t/illegal-html-from-autolinks-in-link-text/9092 "2026-07-28T13:15:40Z")

</div>

\[\<https://domain1.example.com\>\](https://domain2.example.com) The above renders to illegal HTML containing nested a elements: \<p\>\<a href="https://domain2.example.com"\>\<a href="https://domain1.example.com"\>https://domain…

---

## [Bad Interaction Between Laziness Rule and Ordered Lists](https://talk.commonmark.org/t/bad-interaction-between-laziness-rule-and-ordered-lists/9085)

<div class="topic-metadata">

**Author:** [@pugmire](https://talk.commonmark.org/u/pugmire)\
**Replies:** 1\
**Last updated:** [July 10, 2026, 9:14am UTC](https://talk.commonmark.org/t/bad-interaction-between-laziness-rule-and-ordered-lists/9085 "2026-07-10T09:14:54Z")

</div>

I believe I have found an issue with the specification. In particular, the laziness rule for list items, combined with the details about when lists can interrupt paragraphs, together imply an undesirable treatment of ord…

---

## [Shall CommonMark inline inside HTML5 render as CommonMark? If not, why not?](https://talk.commonmark.org/t/shall-commonmark-inline-inside-html5-render-as-commonmark-if-not-why-not/8964)

<div class="topic-metadata">

**Author:** [@rokejulianlockhart](https://talk.commonmark.org/u/rokejulianlockhart)\
**Replies:** 1\
**Last updated:** [June 26, 2026, 12:54pm UTC](https://talk.commonmark.org/t/shall-commonmark-inline-inside-html5-render-as-commonmark-if-not-why-not/8964 "2026-06-26T12:54:12Z")

</div>

At github.com/MALSync/MALSync/issues/2092: …via the available “GitHub-Flavoured Markdown” markup syntax, I am able to utilise CommonMark inside a \<code\> tag, directly inline: 1. \<code\>\[por\](https://www.loc.gov/standa…

---

## [Lazy Continuation Lines in Multiline Setext Headings](https://talk.commonmark.org/t/lazy-continuation-lines-in-multiline-setext-headings/9087)

<div class="topic-metadata">

**Author:** [@pugmire](https://talk.commonmark.org/u/pugmire)\
**Replies:** 0\
**Last updated:** [June 24, 2026, 5:29am UTC](https://talk.commonmark.org/t/lazy-continuation-lines-in-multiline-setext-headings/9087 "2026-06-24T05:29:03Z")

</div>

I’ve found a small disagreement between the spec and commonmark.js. commonmark.js identifies the following as a setext heading within a list item: 1. Foo Bar ==== The spec defines lazy continuation lines such that …

---

## [Precedence of link title over code span](https://talk.commonmark.org/t/precedence-of-link-title-over-code-span/8982)

<div class="topic-metadata">

**Author:** [@taro137](https://talk.commonmark.org/u/taro137)\
**Replies:** 2\
**Last updated:** [June 22, 2026, 3:47pm UTC](https://talk.commonmark.org/t/precedence-of-link-title-over-code-span/8982 "2026-06-22T15:47:56Z")

</div>

In the definition of code spans in the latest 0.31.2 spec, it states: Code span backticks have higher precedence than any other inline constructs except HTML tags and autolinks. However, \[foo\](/ "bar\`baz")\` is tre…

---

## [When the info string already starts with \`language-\`, do not add the \`language-\` prefix](https://talk.commonmark.org/t/when-the-info-string-already-starts-with-language-do-not-add-the-language-prefix/9054)

<div class="topic-metadata">

**Author:** [@znewt99](https://talk.commonmark.org/u/znewt99)\
**Replies:** 2\
**Last updated:** [May 23, 2026, 6:38pm UTC](https://talk.commonmark.org/t/when-the-info-string-already-starts-with-language-do-not-add-the-language-prefix/9054 "2026-05-23T18:38:26Z")

</div>

Should a change be made to the spec, so the behavior of cmark & commonmark.js matches the spec? For context, see commonmark.js issue #277 Here’s what the spec currently says: Although this spec doesn’t mandate any pa…

---

## [Support syntax highlighting for two languages in a small number of cases](https://talk.commonmark.org/t/support-syntax-highlighting-for-two-languages-in-a-small-number-of-cases/4903)

<div class="topic-metadata">

**Author:** [@sedyh](https://talk.commonmark.org/u/sedyh)\
**Replies:** 1\
**Last updated:** [May 22, 2026, 4:32pm UTC](https://talk.commonmark.org/t/support-syntax-highlighting-for-two-languages-in-a-small-number-of-cases/4903 "2026-05-22T16:32:26Z")

</div>

Hello. I’ve encountered that it can be very useful to enable simultaneous syntax highlighting for some exceptional cases. However, we are not talking about complex scenarios like nested language constructs, but about sho…

---

## [Fenced code blocks should add class to \`code\` rather than \`pre\`, matching the HTML best practice](https://talk.commonmark.org/t/fenced-code-blocks-should-add-class-to-code-rather-than-pre-matching-the-html-best-practice/136)

<div class="topic-metadata">

**Author:** [@mathias](https://talk.commonmark.org/u/mathias)\
**Replies:** 7\
**Last updated:** [May 22, 2026, 4:26pm UTC](https://talk.commonmark.org/t/fenced-code-blocks-should-add-class-to-code-rather-than-pre-matching-the-html-best-practice/136 "2026-05-22T16:26:54Z")

</div>

The spec currently says: An info string can be provided after the opening code fence. Opening and closing spaces will be stripped, and the first word is used here to populate the class attribute of the enclosing pre ta…

---

## [\<dfn\>, the define element](https://talk.commonmark.org/t/dfn-the-define-element/3701)

<div class="topic-metadata">

**Author:** [@jtagcat](https://talk.commonmark.org/u/jtagcat)\
**Replies:** 5\
**Last updated:** [April 16, 2026, 8:08pm UTC](https://talk.commonmark.org/t/dfn-the-define-element/3701 "2026-04-16T20:08:53Z")

</div>

I searched around, and didn’t see anyone mention or think about the define element (\<dfn\>). I’m not in this community, and don’t have time to really elaborate. Is it being thought about?

---

## [An RFC for CommonMark?](https://talk.commonmark.org/t/an-rfc-for-commonmark/4157)

<div class="topic-metadata">

**Author:** [@mnot](https://talk.commonmark.org/u/mnot)\
**Replies:** 2\
**Last updated:** [April 11, 2026, 10:24am UTC](https://talk.commonmark.org/t/an-rfc-for-commonmark/4157 "2026-04-11T10:24:35Z")

</div>

I’m wondering if the authors and community are interested in publishing CommonMark in the RFC Series. This would make it easier for other formal specifications (e.g., from the IETF) to reference it. Doing so should be p…

---

## [Proposal for Markdown ruby tag syntax](https://talk.commonmark.org/t/proposal-for-markdown-ruby-tag-syntax/5018)

<div class="topic-metadata">

**Author:** [@chjie](https://talk.commonmark.org/u/chjie)\
**Replies:** 1\
**Last updated:** [April 7, 2026, 7:22pm UTC](https://talk.commonmark.org/t/proposal-for-markdown-ruby-tag-syntax/5018 "2026-04-07T19:22:04Z")

</div>

Title : Proposal for Markdown ruby tag syntax Author : Charles Jie (tw) Email : chjie7@gmail.com Tags : \[markdown ruby syntax\] Revision : 0.2 - formalized by DeepSeek, then refined Created : 2025-05-09 Pr…

---

## [Tildes in info string of fenced code block](https://talk.commonmark.org/t/tildes-in-info-string-of-fenced-code-block/973)

<div class="topic-metadata">

**Author:** [@textnut](https://talk.commonmark.org/u/textnut)\
**Replies:** 2\
**Last updated:** [March 24, 2026, 9:35am UTC](https://talk.commonmark.org/t/tildes-in-info-string-of-fenced-code-block/973 "2026-03-24T09:35:37Z")

</div>

Spec. 4.5 Fenced code blocks, looks only emphasis backtick can not inside info string. What about tildes? Guess it is same with backtick. ~~~ info strong ~~~ not code block? ~~~

---

## [Hierarchy between headings and lists](https://talk.commonmark.org/t/hierarchy-between-headings-and-lists/8972)

<div class="topic-metadata">

**Author:** [@johann1764](https://talk.commonmark.org/u/johann1764)\
**Replies:** 0\
**Last updated:** [October 29, 2025, 4:22pm UTC](https://talk.commonmark.org/t/hierarchy-between-headings-and-lists/8972 "2025-10-29T16:22:58Z")

</div>

I observed a strange behavior of the reference implementation: It seems that headings can be nested into lists, which is odd. I understand that it is technically possible to do that in html, but is that a desirable featu…

---

## [Setext headings](https://talk.commonmark.org/t/setext-headings/8958)

<div class="topic-metadata">

**Author:** [@Thomas](https://talk.commonmark.org/u/Thomas)\
**Replies:** 4\
**Last updated:** [October 13, 2025, 12:30pm UTC](https://talk.commonmark.org/t/setext-headings/8958 "2025-10-13T12:30:24Z")

</div>

Hi :slight\_smile: I want to write in Markdown so that readers can easily read my documents, whether or not they have a Markdown interpreter. As I understand it, Markdown was designed for this purpose. For this purpose,…

---

## [Issues we MUST resolve before 1.0 release \[6 remaining\]](https://talk.commonmark.org/t/issues-we-must-resolve-before-1-0-release-6-remaining/1287)

<div class="topic-metadata">

**Author:** [@jgm](https://talk.commonmark.org/u/jgm)\
**Replies:** 25\
**Last updated:** [October 13, 2025, 12:09pm UTC](https://talk.commonmark.org/t/issues-we-must-resolve-before-1-0-release-6-remaining/1287 "2025-10-13T12:09:50Z")

</div>

Here are some issues in the spec that must be resolved before a 1.0 release. To keep us focused, the optional should resolve issues are in this topic and successfully resolved issues are in this topic. To keep things …

---

## [Cross-references and citations](https://talk.commonmark.org/t/cross-references-and-citations/4013)

<div class="topic-metadata">

**Author:** [@DaveJarvis](https://talk.commonmark.org/u/DaveJarvis)\
**Replies:** 7\
**Last updated:** [September 10, 2025, 7:50pm UTC](https://talk.commonmark.org/t/cross-references-and-citations/4013 "2025-09-10T19:50:21Z")

</div>

Numerous programs have implemented cross-references and citations on top of Markdown. Similar discussions have not resulted in a standard syntax for cross-references and citations added to CommonMark: MultiMarkdown Cro…

---

## [Emphasis and East Asian text](https://talk.commonmark.org/t/emphasis-and-east-asian-text/2491)

<div class="topic-metadata">

**Author:** [@kivikakk](https://talk.commonmark.org/u/kivikakk)\
**Replies:** 14\
**Last updated:** [March 23, 2025, 2:03am UTC](https://talk.commonmark.org/t/emphasis-and-east-asian-text/2491 "2025-03-23T02:03:14Z")

</div>

(I’m sorry to re-open this particular can of worms — I know emphasis parsing is a real pain.) A user raised an issue today regarding how emphasis is treated in the context of East Asian text and punctuation. I’m going t…

---

## [The case for calling it Version 1.0](https://talk.commonmark.org/t/the-case-for-calling-it-version-1-0/4957)

<div class="topic-metadata">

**Author:** [@vas](https://talk.commonmark.org/u/vas)\
**Replies:** 0\
**Last updated:** [March 13, 2025, 12:57am UTC](https://talk.commonmark.org/t/the-case-for-calling-it-version-1-0/4957 "2025-03-13T00:57:31Z")

</div>

Please don’t pile “i agree” or “no!” comments onto the GitHub issue unless you have a new argument for or against, or some other useful additional info. JGM doesn’t need the noise. Use the emoticon reactions to registe…

---

## [Bold failure in Chinese sentence, because of the usage of Chinese punctuation is different from English](https://talk.commonmark.org/t/bold-failure-in-chinese-sentence-because-of-the-usage-of-chinese-punctuation-is-different-from-english/3478)

<div class="topic-metadata">

**Author:** [@keaton](https://talk.commonmark.org/u/keaton)\
**Replies:** 16\
**Last updated:** [February 2, 2025, 12:29pm UTC](https://talk.commonmark.org/t/bold-failure-in-chinese-sentence-because-of-the-usage-of-chinese-punctuation-is-different-from-english/3478 "2025-02-02T12:29:55Z")

</div>

I met bold error, may caused by the usage of Chinese punctuation is different from English. Here are some examples: Error: \*\*水温适度。\*\*水的温度与室温相同，可以有效的减少对胃肠道的刺激，白开水具有生物活性，可以透过细胞膜促进人体的新陈代谢。 \*\*水温适度。\*\*水的温度与室温相同，可以有效的减少对胃肠道的刺激…

---

## [Prefer "angle brackets" over "pointy brackets"](https://talk.commonmark.org/t/prefer-angle-brackets-over-pointy-brackets/4826)

<div class="topic-metadata">

**Author:** [@Wilfred](https://talk.commonmark.org/u/Wilfred)\
**Replies:** 2\
**Last updated:** [January 20, 2025, 12:15am UTC](https://talk.commonmark.org/t/prefer-angle-brackets-over-pointy-brackets/4826 "2025-01-20T00:15:26Z")

</div>

Reading the spec today, I noticed that it uses the term “pointy brackets” for the characters \< and \>. This confused me initially: I’ve not seen this term before, and I wanted to confirm it wasn’t referring to { and } (w…

---

## [Shortcuts with internal brackets, conflicting spec?](https://talk.commonmark.org/t/shortcuts-with-internal-brackets-conflicting-spec/4829)

<div class="topic-metadata">

**Author:** [@gmccullo](https://talk.commonmark.org/u/gmccullo)\
**Replies:** 1\
**Last updated:** [January 18, 2025, 7:57pm UTC](https://talk.commonmark.org/t/shortcuts-with-internal-brackets-conflicting-spec/4829 "2025-01-18T19:57:07Z")

</div>

I’m confused by this rule. On the one hand the spec says: A link label begins with a left bracket (\[ ) and ends with the first right bracket (\] ) that is not backslash-escaped. Between these brackets there must be at l…

---

## [Proposal to Enhance Link Syntax with More Flexible Formatting Options](https://talk.commonmark.org/t/proposal-to-enhance-link-syntax-with-more-flexible-formatting-options/4802)

<div class="topic-metadata">

**Author:** [@segidas](https://talk.commonmark.org/u/segidas)\
**Replies:** 2\
**Last updated:** [December 14, 2024, 7:33am UTC](https://talk.commonmark.org/t/proposal-to-enhance-link-syntax-with-more-flexible-formatting-options/4802 "2024-12-14T07:33:57Z")

</div>

Hello The current CommonMark specification for links is robust and widely used; but it lacks flexibility for certain use cases where enhanced readability / integration with external systems is required. One such limitat…

[Next page](https://talk.commonmark.org/c/spec/6.md?page=1)
