# Footnote extensions vs Link Reference Definition **URL:** \ **Category:** Extensions\ **Created:** [August 14, 2017, 7:59am UTC](https://talk.commonmark.org/t/footnote-extensions-vs-link-reference-definition/2571 "2017-08-14T07:59:35Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![gfx](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/gfx/32/1110_2.png) [@gfx](https://talk.commonmark.org/u/gfx)\ **Post date:** [August 14, 2017, 7:59am UTC](https://talk.commonmark.org/t/footnote-extensions-vs-link-reference-definition/2571/1 "2017-08-14T07:59:35Z")
I need a general agreement of footnote extensions. There are lots of discussions about footnotes, but I can’t find discussions that point the pandoc’s block-style footnote notation conflict with [Link reference definitions](http://spec.commonmark.org/0.28/#link-reference-definitions) in CommonMark. Pandoc’s style footnote notation is like this: [http://pandoc.org/MANUAL.html#footnotes](http://pandoc.org/MANUAL.html#footnotes) ```markdown Here is a footnote reference.[^1] [^1]: Here is the footnote. ``` It means that if a CommonMark-compatible markdown processor has footnotes, it must differ from pandoc’s, while there are lots of CommonMark-incompatible markdown processors that implement pandoc’s footnotes. I think there some choices: 1. Adopt pandoc’s inline-style footnotes (`^[inline-style footnotes]`) 2. Redefine CommonMark to accept pandoc’s block-style footnotes by defining link labels must not have leading `^` 3. GIve up the compatibility with Pandoc’s block-style footnotes (2) seems the best because there are lots of markdown processors that have pandoc’s block-style footnotes. ---
**Author:** ![uasi](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/uasi/32/1228_2.png) [@uasi](https://talk.commonmark.org/u/uasi)\ **Post date:** [August 14, 2017, 8:19am UTC](https://talk.commonmark.org/t/footnote-extensions-vs-link-reference-definition/2571/2 "2017-08-14T08:19:02Z")
Found some related topics in this forum: - [How should footnotes behave?](https://talk.commonmark.org/t/how-should-footnotes-behave/1106) - [Footnotes and indentation](https://talk.commonmark.org/t/footnotes-and-indentation/2030) ---
**Author:** ![chrisalley](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/chrisalley/32/906_2.png) [@chrisalley](https://talk.commonmark.org/u/chrisalley)\ **Post date:** [August 15, 2017, 3:55am UTC](https://talk.commonmark.org/t/footnote-extensions-vs-link-reference-definition/2571/3 "2017-08-15T03:55:00Z")
> [@gfx](#): > > Redefine CommonMark to accept pandoc’s block-style footnotes by defining link labels must not have leading ^ If we went down this route, the core CommonMark spec would need to “know” about a number of other extensions and where not to use particular syntax. Unless we plan in advance all of the extensions, that seems too demanding of the core spec. It might be better to include something in each extension spec stating that you will lose the ability to do X from the CommonMark core feature set if you choose to adopt the extension. ---
**Author:** ![gfx](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/gfx/32/1110_2.png) [@gfx](https://talk.commonmark.org/u/gfx)\ **Post date:** [August 18, 2017, 1:25am UTC](https://talk.commonmark.org/t/footnote-extensions-vs-link-reference-definition/2571/4 "2017-08-18T01:25:44Z")
I don’t think CommonMark must know **all** the syntax extensions but should know footnotes because it is supported by a lot of markdown parsers. In other words, if CommonMark ignores footnotes, markdown parsers that support footnotes could never be compatible with CommonMark. I think there’s another option: to remove link reference definitions from CommonMark. It makes CommonMark simpler, gives markdown parsers with footnotes a possibility to get CommonMark compatibility, and does not break backward compatibility. ---
**Author:** ![notriddle](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/notriddle/32/1237_2.png) [@notriddle](https://talk.commonmark.org/u/notriddle)\ **Post date:** [August 18, 2017, 6:13pm UTC](https://talk.commonmark.org/t/footnote-extensions-vs-link-reference-definition/2571/5 "2017-08-18T18:13:55Z")
Or CommonMark could disallow link references that start with punctuation. I’m betting that the vast majority of link references start with numbers or letters. ---
**Author:** ![gfx](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/gfx/32/1110_2.png) [@gfx](https://talk.commonmark.org/u/gfx)\ **Post date:** [August 23, 2017, 1:56am UTC](https://talk.commonmark.org/t/footnote-extensions-vs-link-reference-definition/2571/6 "2017-08-23T01:56:45Z")
@notriddle Possibly better because the markdown parsers that support footnotes even support link ref definitions too: [https://johnmacfarlane.net/babelmark2/?normalize=1&text=Here+is+a+[link]. Here+is+a+footnote[^footnote]. [link]%3A+http%3A%2F%2Fexample.com+"link+ref+definition" [^footnote]%3A+http%3A%2F%2Fexample.com](https://johnmacfarlane.net/babelmark2/?normalize=1&text=Here+is+a+%5Blink%5D.%0A%0AHere+is+a+footnote%5B%5Efootnote%5D.%0A%0A%5Blink%5D%3A+http%3A%2F%2Fexample.com+%22link+ref+definition%22%0A%0A%5B%5Efootnote%5D%3A+http%3A%2F%2Fexample.com) ---
**Author:** ![notriddle](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/notriddle/32/1237_2.png) [@notriddle](https://talk.commonmark.org/u/notriddle)\ **Post date:** [August 23, 2017, 3:51pm UTC](https://talk.commonmark.org/t/footnote-extensions-vs-link-reference-definition/2571/7 "2017-08-23T15:51:44Z")
Actually, rethinking it, we’d want to exempt quotation marks and maybe a few other pieces of punctuation, too. Like [“this”](http://example.com/). ```markdown Actually, rethinking it, we'd want to exempt quotation marks and maybe a few other pieces of punctuation, too. Like ["this"]. ["this"]: http://example.com/ ``` ---
**Author:** ![gfx](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/gfx/32/1110_2.png) [@gfx](https://talk.commonmark.org/u/gfx)\ **Post date:** [December 18, 2017, 7:02am UTC](https://talk.commonmark.org/t/footnote-extensions-vs-link-reference-definition/2571/8 "2017-12-18T07:02:19Z")
UPDATE: github/cmark now supports Kramdown-style footnotes: [https://github.com/github/cmark/pull/64](https://github.com/github/cmark/pull/64) And thus CommonMarker gem does, so I enables the footnotes-option for my product. ---
**Author:** ![Crissov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/crissov/32/1455_2.png) [@Crissov](https://talk.commonmark.org/u/Crissov)\ **Post date:** [December 18, 2017, 12:41pm UTC](https://talk.commonmark.org/t/footnote-extensions-vs-link-reference-definition/2571/9 "2017-12-18T12:41:05Z")
Babelmark 3 currently interfaces with “GitHub Flavored Markdown”, i.e. cmark-gfm, version 0.17.4, which does not seem to have this extension enabled yet. [GitHub’s documentation `extensions.txt`](https://github.com/github/cmark/blob/master/test/extensions.txt) should probably be written more like `spec.txt`. It is missing several edge cases right now. Anyway, I did not really get the point of this thread. No other implementation seems to support Pandoc’s inline footnotes with a circumflex preceding bracketed text, `^[footnote]`, and automatically generated mark. MMD will turn the link label `[^footnote]` into inline footnote text if it cannot be resolved to a reference link definition. Many existing implementations largely agree with CM about [_link labels_](http://spec.commonmark.org/0.28/#link-label) which start with a circumflex, so will try to turn them into links. If the respective reference link definition only contains a single string without whitespace, it will be used as the URL. I believe CM could be prepared better for extensions if reference link definitions were slightly changed: the _link destination_ should be optional when a _link title_ (in parentheses, single or double quotation marks) follows (or possibly any part of an _info string_ that cannot be interpreted as the destination URL). However, feeding empty or degenerate URLs did not have the expected results in CM-compatible implementations and some others – at least unless I separate the ill-formed link definitions from the rest by blank lines. An extension or postprocessor that hooks into the AST could simply check whether the first character of `` within `` is `^` and then modify it accordingly. This also avoid stuff like parsing the destination `#` as the start of a heading, which is something that happens in several implementations that support footnotes. Link titles, which become footnote texts, do not support blank lines inside and thus no paragraphs, but may contain inline formatting. A minor drawback perhaps, the original location of the link definition will be lost already at this point, so all notes will necessarily be automatically placed at either the (page) foot or the (document) end. [Babelmark 3](https://babelmark.github.io/?text=Single+word%5B%5E1%5D++%0AMultiple+words%5B%5E2%5D++%0AQuoted+words%5B%5E3%5D++%0AHash+URL%5B%5E4%5D++%0ADot+URL%5B%5E5%5D++%0AEmpty+URL%5B%5E6%5D++%0A%0A%5B%5E1%5D%3A+Note%0A%0A%5B%5E2%5D%3A+several+words%0A%0A%5B%5E3%5D%3A+%22quoted+text%22%0A%0A%5B%5E4%5D%3A+%23+%22link+title+or+heading%22%0A%0A%5B%5E5%5D%3A+.+%22link+title%22%0A%0A%5B%5E6%5D%3A+%3C%3E+%22link+title%22%0A) [Dingus](http://spec.commonmark.org/dingus/?text=Single%20word%5B%5E1%5D%20%20%0AMultiple%20words%5B%5E2%5D%20%20%0AQuoted%20words%5B%5E3%5D%20%20%0AHash%20URL%5B%5E4%5D%20%20%0ADot%20URL%5B%5E5%5D%20%20%0AEmpty%20URL%5B%5E6%5D%20%20%0AURL%5B%5E7%5D%20%20%0A%0A%5B%5E1%5D%3A%20Note%0A%0A%5B%5E2%5D%3A%20several%20words%0A%0A%5B%5E3%5D%3A%20%22quoted%20text%22%0A%0A%5B%5E4%5D%3A%20%23%20%22link%20title%20or%20heading%22%0A%0A%5B%5E5%5D%3A%20.%20%22link%20title%22%0A%0A%5B%5E6%5D%3A%20%3C%3E%20%22link%20title%22%0A%0A%5B%5E7%5D%3A%20destination%20%22link%20title%22) PS: The reference implementations do not agree about empty URLs inside angle brackets: ``` [label]: <> "title" ``` > A [link destination](http://spec.commonmark.org/0.28/#link-destination) consists of either > > - a sequence of zero or more characters between an opening `<` and a closing `>` …