Related topics
- Consistent attribute syntax: 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: 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: 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: Info strings could be used for finer control of enumeration.
- MultiMarkdown Cross References: 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