# Info strings for suffixed headings **URL:** \ **Category:** Spec\ **Tags:** release-1.0\ **Created:** [August 26, 2018, 11:53am UTC](https://talk.commonmark.org/t/info-strings-for-suffixed-headings/2902 "2018-08-26T11:53:01Z")\ **Posts on this page:** 7\ **Page:** 1
**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, 11:53am UTC](https://talk.commonmark.org/t/info-strings-for-suffixed-headings/2902/1 "2018-08-26T11:53:01Z")
[https://github.com/commonmark/CommonMark/issues/500](https://github.com/commonmark/CommonMark/issues/500) # Related topics - [Info strings elsewhere](https://talk.commonmark.org/t/info-strings-elsewhere/2610) - [Consistent attribute syntax](https://talk.commonmark.org/t/consistent-attribute-syntax/272) - [Feature request: automatically generated ids for headers](https://talk.commonmark.org/t/feature-request-automatically-generated-ids-for-headers/115) - [Anchors in markdown](https://talk.commonmark.org/t/anchors-in-markdown/247/20) - [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) - [MultiMarkdown Cross References](https://talk.commonmark.org/t/multimarkdown-cross-references/1915) @jgm closed issue #500 on Github, suggesting we discuss it here, so Iʼm quoting most of it below: # Status quo (0.28) > An [ATX heading](http://spec.commonmark.org/0.28/#atx-headings) consists of a string of characters, parsed as inline content, between an opening sequence of 1–6 unescaped `#` characters and an optional closing sequence of **any number** of unescaped `#` characters. [Emphasis mine.] ## Valid heading suffixes from spec examples ```markdown ## foo ## ### bar ### # foo ################################## ##### foo ## ### foo ### ``` ## Invalid heading suffixes ```markdown ### foo ### b # foo# ### foo \### ## foo #\## # foo \# ``` # Proposal I wish we can somewhat relax the rule for the closing sequence of `#` characters. I want to enable something like an _info string_ for future extensions: If the number of unescaped `#` characters in the opening sequence is matched exactly by the number of unescaped `#` characters in a possible closing sequence with a space on both sides, the characters after this closing sequence form an _info string_ and are not used verbatim for output. Only [example 44](http://spec.commonmark.org/0.28/#example-44) would be affected by this change: ```markdown ### foo ### b .

foo

``` instead of ```markdown ### foo ### b .

foo ### b

``` Also: ```markdown ### foo ### ### ### foo ### ## ### foo ## ### ### foo ## ### ## .

foo

foo

foo ##

foo ##

``` And: ```markdown # foo `#` # foo ` # ` .

foo #

foo `

``` … where I’m not completely sure about the last one. ## Common use cases ```markdown # foo # #bar .baz "quuz" # foo # {id=bar class=baz title=quuz} .

foo

foo

``` The string either inside quotation marks `""` or parentheses `()` would be used in the HTML `title` attribute, but also in a table of contents, i.e. LaTeX (`book`) equivalence would be like this: ```markdown # foo # "bar" # foo # (bar) . \chapter[bar]{foo} \chapter[bar]{foo} ``` There could also be an extension that made headings not have an auto-generated number or not being included in the ToC, or both, e.g.: ```markdown # foo # - . \chapter*{foo} ``` Iʼm _not_ proposing the `#id .class "title" @attribute key=value` syntax (nor any other) for the _info string_, just that there be an optional _info string_ in ATX headings. ## Impact I do not have a corpus available to test this proposal with, but I expect there to be very little existing content that would be affected by the change, because the hash or number sign `#` is very unlikely to occur within a heading (or prose in general) with spaces on both sides of it. A string of `#` characters is even less likely. Authors who are talking of the character itself will very likely mark it up with directly adjacent backticks or quotation marks. ## Consequences People would probably also like to have _info strings_ for setext headings if they were available for ATX headings. Their `=` and `-` underlines do not allow any contents in the same line either. A possible, but hackish, solution would be to only consider trailing characters for an _info string_ if the underline length matches the characters in the (last line of the) heading. I am not proposing this behavior right now. ```markdown foo === #bar .baz "quuz" foo --- #bar .baz "quuz" .

foo

foo

``` ```markdown foo == == #bar .baz "quuz" foo - #bar .baz "quuz" .

foo == == #bar .baz "quuz" foo

``` More ideas like this are discussed in [Info strings elsewhere](https://talk.commonmark.org/t/info-strings-elsewhere/2610). ---
**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 28, 2018, 12:42pm UTC](https://talk.commonmark.org/t/info-strings-for-suffixed-headings/2902/2 "2018-08-28T12:42:51Z")
_Poll ([view on site](https://talk.commonmark.org/t/info-strings-for-suffixed-headings/2902/2))_ It would be nice to explain dissent in a comment below. ---
**Author:** ![digitalmoksha](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/d/53a042/32.png) [@digitalmoksha](https://talk.commonmark.org/u/digitalmoksha)\ **Post date:** [September 3, 2018, 1:35am UTC](https://talk.commonmark.org/t/info-strings-for-suffixed-headings/2902/3 "2018-09-03T01:35:41Z")
I guess I’m unclear what benefit this has over a more generic attribute extension that can be used in many places, such as that used by Pandoc or kramdown, like adding `{#identifier .class .class key=value key=value}`. > If the number of unescaped `#` characters in the opening sequence is matched exactly by the number of unescaped `#` characters in a possible closing sequence with a space on both sides, the characters after this closing sequence form an _info string_ and are not used verbatim for output. I feel like this style is going to get complicated when trying to extend this functionality to other elements. Intuitively, I feel like having a consistent attribute syntax, as talked about [here](https://talk.commonmark.org/t/consistent-attribute-syntax/272) would be a better overall solution. In fact, I wish we would just either choose the Pandoc or kramdown style, tweak if necessary, and get it done 😉 It’s really something that’s needed… ---
**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:** [September 3, 2018, 6:08am UTC](https://talk.commonmark.org/t/info-strings-for-suffixed-headings/2902/4 "2018-09-03T06:08:36Z")
One benefit is that it makes existing attribute extensions partially compatible if written in a specific way: consider curly braces _optional_ wrappers around indo strings, but required in places where info strings are otherwise impossible or for line breaks inside. ````markdown ## Heading ## {info string within optional wrappers} ![text](target "title" {info string within optional wrappers}) or ![text](target {"title" info string within optional wrappers}) [label] label: {info string within optional wrappers} ``` {info string within optional wrappers} ``` ```` > [@Info strings elsewhere](https://talk.commonmark.org/t/info-strings-elsewhere/2610): > > ## 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 … ---
**Author:** ![digitalmoksha](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/d/53a042/32.png) [@digitalmoksha](https://talk.commonmark.org/u/digitalmoksha)\ **Post date:** [September 3, 2018, 11:50am UTC](https://talk.commonmark.org/t/info-strings-for-suffixed-headings/2902/5 "2018-09-03T11:50:30Z")
It seems like allowing for optional wrappers adds unnecessary complexity. Since the syntax for the wrappers needs to be defined anyway, why not just always require them. It feels like we’re trying to implement a solution (with all it’s inherent edge cases) to solve a problem we should be addressing headon: a valid attribute syntax, that most people agree is needed. If we could solve that, it’s edge cases, with a strict and simple syntax - then we could look at relaxing the need for wrappers in certain cases. > One benefit is that it makes existing attribute extensions partially compatible if written in a specific way You’re right, but I think that might start leading to more fragmentation. I don’t think we should allow for multiple attribute extension syntaxes - there should be one well defined one, with some well defined attributes (such as width) but with the flexibility for any key/value pairs. It seems like your info string is basically the same as the attribute string, we’re just wrangling over how to implement it 😉 ---
**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:** [September 3, 2018, 8:11pm UTC](https://talk.commonmark.org/t/info-strings-for-suffixed-headings/2902/6 "2018-09-03T20:11:24Z")
The point is that there will be no generic curly attribute syntax in vanilla 1.0, because it would be too much a deviation from Markdown. It may always stay an optional extension. Additional opportunities for the established concept of info strings, however, could be worth the necessary minor syntax tweaks. Also keep in mind that source readability is a major design feature of MD/CM and restricting places for info strings can actually guarantee that better than a very generic syntax for auxiliary data. ---
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [September 4, 2018, 4:51pm UTC](https://talk.commonmark.org/t/info-strings-for-suffixed-headings/2902/7 "2018-09-04T16:51:33Z")
I agree that in the long run a consistent attribute syntax is the way to go. The “info string” idea for code blocks was a kind of compromise, which left room for attributes without specifying any particular syntax.