I admit that I missed to comment on this in the original discussion of fenced code block, but nevertheless here goes.
In the current spec, a fenced code block is closed by a fence
with at least as many backticks or tildes as the opening code fence.
I would prefer to change this to
with exactly as many backticks or tildes as the opening code fence.
This would be consistent with the relation between opening and closing backtick strings in code spans, and I don’t see a good reason why one would want to close a fenced code block with a number of backticks that’s different from the number in the opening fence.
I take your point about the symmetry with the way inline code spans
operate. But here are two reasons for allowing the closing string of
backticks or tildes to be longer than the opening string:
It’s easy to see visually that one line is longer than another.
Determining whether it has exactly the same length is harder.
The current rule allows you to close a fenced code block without
going back and counting how many backticks there are; you just
mash the backtick key until you’ve got a line that’s clearly longer.
If the opening fence includes a language specification (or other
info string), then it can be aesthetically nicer to make the closing
fence longer, so that it occupies the space that was occupied by
the language specification in the opening fence.
I’m not sure which reasons are stronger, and it would be good to
hear other views on this.
I thought it would be useful to give a bit of history here, because I think there are two different ways of thinking about fenced code blocks.
Although many people seem to think github invented them, that is not the case. Look at these two threads from the markdown-discuss list from 2007: “seemingly no good way to end bulleted list and start code block” and “Flat code block syntax.” As you can see, the intent was to formalize something like the old email convention of
---%< snip --------------------
where a long horizontal delimiter sets off a section visually. So the original thought (at least mine) was that the lines would normally be quite long, to make the visuals clear. If they are long, it’s asking a lot to make the writer reproduce a line of exactly the same length – easier to allow one that is longer.
I think github’s motivations may have been different (I don’t know if they were even familiar with this prior art): generalizing the inline backtick syntax to blocks, in something like the way that python’s """ generalizes single-line strings to multi-line. (Just guessing here.) Your point presupposes this understanding, so I just wanted to point out that it’s not the only way to think of the motivation for fenced code blocks.