# Info strings elsewhere

**URL:** <https://talk.commonmark.org/t/info-strings-elsewhere/2610>\
**Category:** Spec\
**Created:** [October 4, 2017, 8:00am UTC](https://talk.commonmark.org/t/info-strings-elsewhere/2610 "2017-10-04T08:00:59Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**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:** [October 4, 2017, 8:00am UTC](https://talk.commonmark.org/t/info-strings-elsewhere/2610/1 "2017-10-04T08:00:59Z")

</div>

> <https://github.com/commonmark/CommonMark/issues/500>

```markdown
## Heading # still heading
## Heading ## info string
## Heading ### still heading
## Heading## still heading
## Heading ##still heading
## Heading # # still heading

```

[Babelmark](https://babelmark.github.io/?text=%23%23+Heading+%23+still+heading%0A%0A%23%23+Heading+%23%23+info+string%0A%0A%23%23+Heading+%23%23%23+still+heading%0A%0A%23%23+Heading%23%23+still+heading%0A%0A%23%23+Heading+%23%23still+heading%0A%0A%23%23+Heading+%23+%23+still+heading%0A)

In the Github issue I’m requesting a small syntax change to enable _info strings_, as known from fenced code blocks, for suffixed ATX headings. I believe they are the perfect entry point for many kinds of extensions. Even if not parsed further, _info strings_ can be considered comments that will not appear in the output. I am not proposing a certain syntax for the _info string_ itself here. I just want to collect and discuss ideas how to enable them elsewhere.

## Setext headings

Suggestion: the number of dashes `-` or equals signs `=` must match the number of characters in (the first/last/shortest/longest line of) the heading (without leading and trailing whitespace) for successive characters after a whitespace to be considered an _info string_.

```markdown
Heading
------ no, a paragraph

Heading
------- info string

Heading
-------- no, a paragraph

```

[Babelmark](https://babelmark.github.io/?text=Heading%0A------+no%2C+a+paragraph%0A%0AHeading%0A-------+info+string%0A%0AHeading%0A--------+no%2C+a+paragraph%0A)

## Quotations

Quotations are complicated, due to lazy wrapping. An approach similar to the one I’m proposing for ATX headings might work, though.

```markdown
>> Quotation < more quotation

>> Quotation << info string

>> Quotation <<< more quotation

>> Quotation <<more quotation

>> Quotation<< more quotation

>>Quotation << info string?

>> Quotation 
<< info string?

```

[Babelmark](https://babelmark.github.io/?text=%3E%3E+Quotation+%3C+more+quotation%0A%0A%3E%3E+Quotation+%3C%3C+info+string%0A%0A%3E%3E+Quotation+%3C%3C%3C+more+quotation%0A%0A%3E%3E+Quotation+%3C%3Cmore+quotation%0A%0A%3E%3E+Quotation%3C%3C+more+quotation%0A%0A%3E%3EQuotation+%3C%3C+info+string%3F%0A%0A%3E%3E+Quotation+%0A%3C%3C+info+string%3F%0A)

## List items

Unlike HTML, Commonmark has no explicit markup for lists. They are made implicitly from consecutive list items. We could try the same approach as proposed for headings, but unfortunately, the bullet characters are rather likely to appear verbatim with spaces on both sides. The situation is better for numbered lists. In any case, it would probably make sense to restrict _info strings_ to the first line of a list item or to single-line items, because otherwise it gets really confusing and probably ambiguous with nested lists.

```markdown
* List item * info string?
* List item + more list item
* List item - more list item

+ List item * more list item
+ List item + info string?
+ List item - more list item

- List item * more list item
- List item + more list item
- List item - info string?

1. List item . info string
1) List item ) info string

```

[Babelmark](https://babelmark.github.io/?text=*+List+item+*+info+string%3F%0A*+List+item+%2B+more+list+item%0A*+List+item+-+more+list+item%0A%0A ____%0A%2B+List+item+*+more+list+item%0A%2B+List+item+%2B+info+string%3F%0A%2B+List+item+-+more+list+item%0A%0A____ %0A-+List+item+*+more+list+item%0A-+List+item+%2B+more+list+item%0A-+List+item+-+info+string%3F%0A%0A ____%0A1.+List+item+.+info+string%0A%0A____ %0A1%29+List+item+%29+info+string%0A)

## Thematic breaks

We could require a certain pattern of whitespaces and only dashes, only asterisks or only underlines to allow an _info string_ after it, e.g. three times three characters separated by three spaces, but that’s a really arbitrary choice to make.

```markdown
--- --- --- info string
****** *** info string
______ ___ info string

```

[Babelmark](https://babelmark.github.io/?text=--+--+--+--+--+--+info+string%0A%0A ***+++*** +++***+++info+string%0A%0A ____++____ ++ ____ ++info+string%0A)

This has many problems in existing implementations because two or three dashes may be combined into an en or em dash (_Smartypants_), respectively, while consecutive asterisks and underscores may be interpreted as emphasis markup.

## Link definitions

One could consider the link title in parentheses or plain quotation marks as a rudimentary _info string_. That means, any additional information would just follow after it. In other words, everything after the first whitespace after the link address is considered an info string and the title syntax is the only part of it that is described in the core spec.

```markdown
  [link-id]: http://example.com
  [link-id]: http://example.com "title" info string
  [link-id]: http://example.com (title) info string
  [link-id]: <http://example.com>
  [link-id]: <http://example.com> "title" info string
  [link-id]: <http://example.com> (title) info string

```

[Babelmark](https://babelmark.github.io/?text=Links%3A+%5Blink1%5D%2C+%5Blink2%5D%2C+%5Blink3%5D%2C+%5Blink4%5D%2C+%5Blink5%5D%2C+%5Blink6%5D%2C+%5Blink7%5D%2C+%5Blink8%5D%2C+%5Blink9%5D%2C+%5Blink10%5D.%0A%0A++%5Blink1%5D%3A+http%3A%2F%2Fexample.com%0A++%5Blink2%5D%3A+http%3A%2F%2Fexample.com+%22title%22%0A++%5Blink3%5D%3A+http%3A%2F%2Fexample.com+%22title%22+info+string%0A++%5Blink4%5D%3A+http%3A%2F%2Fexample.com+(title)%0A++%5Blink5%5D%3A+http%3A%2F%2Fexample.com+(title)+info+string%0A++%5Blink6%5D%3A+%3Chttp%3A%2F%2Fexample.com%3E%0A++%5Blink7%5D%3A+%3Chttp%3A%2F%2Fexample.com%3E+%22title%22%0A++%5Blink8%5D%3A+%3Chttp%3A%2F%2Fexample.com%3E+%22title%22+info+string%0A++%5Blink9%5D%3A+%3Chttp%3A%2F%2Fexample.com%3E+(title)%0A++%5Blink10%5D%3A+%3Chttp%3A%2F%2Fexample.com%3E+(title)+info+string%0A)

Note that `#`, `?` and perhaps even `;` can be considered minimal relative URLs that can safely be ignored. This may be useful for certain extensions.

## Inline links

Basically the same considerations as for link definitions also apply to inline links, although existing support there is less universal.

```markdown
[link text](http://example.com "title" info string)

```

[Babelmark](https://babelmark.github.io/?text=%5Blink+text%5D(http%3A%2F%2Fexample.com+%22title%22+info+string)%0A)

One could argue that URLs inside angle brackets should allow spaces and other characters that need to be percent-encoded. This would probably negate the possibility of _info strings_ therein.

```markdown
<http://example.com part of the address>

```

[Babelmark](https://babelmark.github.io/?text=%3Chttp%3A%2F%2Fexample.com+part+of+the+address%3E%0A)

---

<div class="post-metadata">

**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:** [October 5, 2017, 11:43pm UTC](https://talk.commonmark.org/t/info-strings-elsewhere/2610/2 "2017-10-05T23:43:20Z")

</div>

## Related topics

- [Consistent attribute syntax](https://talk.commonmark.org/t/consistent-attribute-syntax/272): The _info string_ solution cannot apply to all CM markup types, but it also does not add additional markup characters like the proposed curly braces.
- [Feature request: automatically generated ids for headers](https://talk.commonmark.org/t/feature-request-automatically-generated-ids-for-headers/115): While automatically generated, _implicit_ IDs are great, though not as simple as a first look might suggest, _info strings_ could be used for manual, _explicit_ IDs, e.g. with the popular `#id` syntax inspired by CSS Selectors.
- [Anchors in markdown](https://talk.commonmark.org/t/anchors-in-markdown/247/20): With _info strings_ you don’t get anchors (i.e. IDs) at arbitrary locations, but at least in the most frequently needed ones, i.e. blocks and links.
- [Enumerated lists without explicit number, ATX headings with explicit number](https://talk.commonmark.org/t/enumerated-lists-without-explicit-number-atx-headings-with-explicit-number/1951): _Info strings_ could be used for finer control of enumeration.
- [MultiMarkdown Cross References](https://talk.commonmark.org/t/multimarkdown-cross-references/1915): While mostly orthogonal to MMD’s syntax extension, _info strings_ could help with referencing other parts of the document.

## Possible internal _info string_ syntax

The exact use and syntax of _info strings_ should not be specified by Commonmark, but most parsers would probably agree on some common extensions:

- `#id` unique identifier, usable as a anchor, i.e. a link target, for instance (not a hash-tag)
- `.class` named category, type or class, e.g. for styling or specialized behavior
- `"title"`, `'title'`, maybe `(title)` alternative or additional textual content, e.g. for a table of contents or a tool tip
- `key=value` arbitrary parameters or attributes that may only be useful for a certain output format or processor

Other syntax extensions for _info strings_ are less common:

- `@attribute` a boolean property that should be activated (`true`), can also be a semantic category (not a mention)
- `$variable`, `$value`
- `{template}`, `{{template}}`
- `:lang`, `((lang))` a BCP47 language code

---

<div class="post-metadata">

**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:** [November 1, 2017, 2:01am UTC](https://talk.commonmark.org/t/info-strings-elsewhere/2610/3 "2017-11-01T02:01:44Z")

</div>

## Autolinks

Without more changes, autolinks could either support info strings or spaces in absolute URLs, but not both.

Assuming we preferred _info strings_, should they be dropped from, retained for or even used as the link text?

```markdown
<http://foo.bar/baz info string>

```

```auto
<p><a href="http://foo.bar/baz">http://foo.bar/baz</a></p>
<p><a href="http://foo.bar/baz">http://foo.bar/baz info string</a></p>
<p><a href="http://foo.bar/baz">info string</a></p>

```

---

<div class="post-metadata">

**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:** [August 26, 2018, 12:13pm UTC](https://talk.commonmark.org/t/info-strings-elsewhere/2610/4 "2018-08-26T12:13:30Z")

</div>

## List items 2

For enumerated lists with parentheses, reversing the marker would be possible as well:

```markdown
1) List item ) more list item
1) List item ( info string
1) List item (1 info string? 
1) List item 1( more list item

```

## Autolinks 2

The example may be clearer this way:

```markdown
<http://foo.bar/baz #info .string>

```

```markdown
<p><a href="http://foo.bar/baz" id="info" class="string">http://foo.bar/baz</a></p>
<p><a href="http://foo.bar/baz" id="info" class="string">http://foo.bar/baz #info .string</a></p>
<p><a href="http://foo.bar/baz" id="info" class="string">info string</a></p>

```

I strongly suggest we stay with automatically converted spaces, though:

```markdown
<p><a href="http://foo.bar/baz%20#info%20.string">http://foo.bar/baz #info .string</a></p>

```

---

<div class="post-metadata">

**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 29, 2018, 5:13am UTC](https://talk.commonmark.org/t/info-strings-elsewhere/2610/5 "2018-08-29T05:13:56Z")

</div>

Given that this proposal adds quite a few syntax rules (and thus additional test cases), and the community’s desire to stabilise the core spec, should we move this to “Extensions”?

---

<div class="post-metadata">

**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:** [August 29, 2018, 9:07pm UTC](https://talk.commonmark.org/t/info-strings-elsewhere/2610/6 "2018-08-29T21:07:50Z")

</div>

The info strings enable extensions but the syntax itself belongs into the core, preferably in 1.0, because we donʼt want breaking changes later.

---

<div class="post-metadata">

**Author:** ![aoudad](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/a/b782af/32.png) [@aoudad](https://talk.commonmark.org/u/aoudad)\
**Post date:** [February 18, 2019, 1:59am UTC](https://talk.commonmark.org/t/info-strings-elsewhere/2610/7 "2019-02-18T01:59:37Z")

</div>

How about…

```java
{.class #id key="value" info="Arbitrary info string"}

```

This provides maximum flexibility for future extensions, since any info string could be applied in any location where [attribute blocks](https://talk.commonmark.org/t/consistent-attribute-syntax/272) (or [attribute references](https://talk.commonmark.org/t/attribute-references/3076)) can be applied.

It’s additional markup, but it keeps things future-compatible – consistent attribute syntax will almost inevitably be added to CommonMark core or a standard extension.

---

<div class="post-metadata">

**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:** [February 18, 2019, 5:25am UTC](https://talk.commonmark.org/t/info-strings-elsewhere/2610/8 "2019-02-18T05:25:13Z")

</div>

I’m in favour of using consistent attribute syntax for info strings too, rather than adding a bunch of new syntax rules relating to the placement of the info string.

Also, by keeping text that isn’t rendered in the visible output of the document inside of curly braces there’s a clear seperation of concerns. I realise that fenced code blocks already can have info strings outside of curly braces; that’s unfortunate, but too late to change now. So maybe info strings outside of curly braces could be reserved for fenced block elements only.