Clarification on code fence and ` or ~ in info string


I’m implementing a CommonMark parser and I’m working on fenced code blocks. The spec is explicit that fences starting with ` must not include ` in the info string in order to make it easy to deal with inline code spans. I’ve noticed that a similar restriction exists in the implementation for ~ characters in the info string of a fence starting with ~. This is not in the spec and you have mentioned here that the spec and implementation should be brought together in this regard.

Do you have any thoughts on how to square the spec and implementation? I.e., the implementation is right and the spec needs to reflect that or the spec is right and the implementation needs to reflect that? I think the implementation behavior is probably correct given that the GFM spec uses ~ for strikethrough spans and a similar parsing issue could occur.

Please let me know which approach I should take. I’m also happy to make a PR with spec changes.



Anyone? :slight_smile:



I concluded that (a) there was not the same reason to forbid ~ in info strings in a tilde-fenced block that there is to forbid ` in a backtick-fenced block, and (b) that there is some reason to allow tildes, to give the possibility of pretty formatting. I think (b) is a pretty weak reason, and you’re right that there’s a potential conflict down the road if we support ~~ for strikeout, as many implentations do.

So, it’s probably best to change the spec here to align with the current behavior of implementations. I’d be interested in whether anyone has a different view.

1 Like