ATX header ambiguity (?)

Spec
1

A sequence of # characters with a nonspace character following it is not a closing sequence, but counts as part of the contents of the header:

This makes it ambiguous whether

# My ATX header #\#

should render to

<h1>My ATX header ##</h1>

or

<h1>My ATX header</h1>

This is especially true given that escaping closing sequences is valid as shown in example 36.

The try renderer currently renders it as

<h1>My ATX header #\</h1>

which is odd.

2

I don’t think there is really any ambiguity. “An ATX header 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 # characters.” So we need to ask whether

#\#

in your example counts as “an optional closing sequence of any number of # characters.” Example 36 does not show that “escaping closing sequences is valid”; it is meant to illustrate the explicit statement in the spec that “backslash-escaped # characters do not count as part of the closing sequence.” So, given what the spec says, the ending sequence in your example is not a closing sequence of # characters.

I think this is a bug in the js implementation. (The C implementation gets it right.) And it shows we need an example in the spec like yours. Can you submit this as an issue on the stmd issue tracker?

3

I would say that this behavior gets decided by Example 35:

A sequence of # characters with a nonspace character following it is not a closing sequence, but counts as part of the contents of the header:

Example 35

 ### foo ### b

→ 

 <h3>foo ### b</h3>

So, I think this is how it is interpreted:

# My ATX header #\#
|               | |
|               | \- Part of the ATX header text
|               \- Part of the ATX header text
\- Beginning of the ATX header

And it should therefore be:

<h1>My ATX Header##</h1>
4

I opened https://github.com/jgm/stmd/issues/16 before I stumbled over this thread, so it seems we found the same issue :wink:

5

Well, the spec explicitly says that backslash-escaped # characters are
not counted as part of the closing sequence. So, the final # is not
a closing sequence.

6

The bug has been fixed and a test case added. Thanks!