## Heading # still heading ## Heading ## info string ## Heading ### still heading ## Heading## still heading ## Heading ##still heading ## Heading # # still heading
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.
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.
Heading ------ no, a paragraph Heading ------- info string Heading -------- no, a paragraph
Quotations are complicated, due to lazy wrapping. An approach similar to the one I’m proposing for ATX headings might work, though.
>> Quotation < more quotation >> Quotation << info string >> Quotation <<< more quotation >> Quotation <<more quotation >> Quotation<< more quotation >>Quotation << info string? >> Quotation << info string?
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.
* 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
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.
--- --- --- info string *** *** *** info string ___ ___ ___ info string
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.
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.
[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
? and perhaps even
; can be considered minimal relative URLs that can safely be ignored. This may be useful for certain extensions.
Basically the same considerations as for link definitions also apply to inline links, although existing support there is less universal.
[link text](http://example.com "title" info string)
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.
<http://example.com part of the address>