# 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:** 1\
**Showing post:** 2

<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

---

_[View the full topic](https://talk.commonmark.org/t/info-strings-elsewhere/2610)._