Implement ```-style (fenced) Markdown code blocks

Question

Currently, Stack Exchange’s Markdown parser only allows four-space indents to represent code blocks:

    // some code
    // another line of code

GitHub Flavored Markdown and other Markdown implementations allow for an alternative syntax, that doesn’t require indenting each code line:

```
// some code
// another line of code
```

This is much more convenient to type out. It would be super useful if Stack Exchange could support this syntax.

---

By extension, this syntax also allow you to specify the source language right after the opening ```:

```js
// some code
// another line of code
```

…which would then enable syntax highlighting for that specific language. Although it’s interesting metadata, I don’t think this feature is needed on Stack Overflow, as the syntax highlighting library works pretty well for various languages.

So, even if you would allow this syntax but ignore the ```language, this would greatly improve my productivity on Stack Exchange.

What do you think?

The moderators are currently collecting feedback regarding this feature, so please post a comment with your thoughts. Good idea? Bad idea? Don’t really care? What do you think are the benefits/drawbacks? Experiences? Let them know! Thanks!

Answer 1

Code fences work now.

function DeepThought(task) {
    this.task = task;
}
DeepThought.prototype.answer = function () {
    switch (this.task) {
        case "life, universe, and everything": return 42;
        default: throw "not implemented";
    }
}

(view source on this answer)

As much as that's possible for a partial feature, they are compliant with CommonMark 0.28. That means:

• A code fence consists of three or more backticks ``` or tildes ~~~, indented by zero to three spaces.
• The opening fence can be followed by a syntax indicator. On Stack Exchange, this can be a Prettify module name (e.g. ```lang-cxx) or a tag for which syntax highlighting has been configured (e.g. ```c++). ```none disables syntax highlighting.
• The closing code fence needs to use the same character, and at least the same number as the opening code fence.

• The code block will be de-dented by as many spaces as the opening code fence was indented with. So this:

  See this:
    ~~~
    foo
      bar
    ~~~
  

  turns into this:

  See this:

  foo
    bar
  

• An unclosed fenced codeblock continues to the end of the block (e.g. block quote) or post.

That last point is also the reason for the only real edge case breakage that this causes with existing content. If somebody created a horizontal line in a post with something like ~~~~~~~~~~~~~~, that is now going to open a code block. As always when we make markdown changes, the question & answer view is not going to be impacted by this unless the post is edited, and it's extremely rare, so I'm not too worried about this.

Answer 2

Benefits

• Compatibility with GitHub-Flavored Markdown and other Markdown libraries that support this de facto standard (and possibly its variants). This enables copy-pasting from gists or Markdown files within repositories, which can be useful on programming-related sites like Stack Overflow.
• The triple backtick syntax is easier and faster to type than indenting each line of code with four spaces.
• Saves some storage in the database, too! ;)

All the above benefits apply to the new syntax, even without the additional functionality to specify the programming language. With that functionality, I’ll add another (huge) benefit:

• As it’s much easier to specify the language of code blocks using this syntax (compared to the current syntax), I wouldn’t be surprised if this change caused more people to explicitly declare the programming language, so that the syntax highlighting can be more accurate. This is useful for answers that include, e.g. separate HTML and CSS code blocks.

Drawbacks

I honestly can’t think of any. It’s very likely no one is using the triple backtick-syntax at the moment as it doesn’t work; so I doubt it will break anything. If you don’t like the new syntax, feel free to stick to the old one.

Experiences

Ever since GitHub enabled this syntax, I’ve grown accustomed to it. I ♥ triple backtick syntax, and every time I’m forced to go back to the four-space-indent syntax, it feels awkward.

Answer 3

I don't really care either way whether this gets implemented: it's a superfluous extension to Markdown (unlike, say, inline HTML, spoiler markdown, or the as-yet-unimplemented-on-Stack-Exchange table syntax), but it is true the fenced code block has been added to pretty much every Markdown library that doesn't stick to just the original spec.

However, the triple backtick syntax is a GitHub extension, and it's not exactly the "de facto standard" Mathias Bynens portrays it as.

Fenced code blocks, as far as I understand it, were first introduced in the PHP Markdown Extra library as the following:

Fenced code blocks are like Markdown’s regular code blocks, except that they’re not indented and instead rely on a start and end fence lines to delimit the code block. The code block start with a line containing three or more tilde ~ characters, and ends with the first line with the same number of tilde ~. For instance:

This is a paragraph introducing:

~~~~~~~~~~~~~~~~~~~~~
a one-line code block
~~~~~~~~~~~~~~~~~~~~~

Other implementations followed suit, by either supporting only 3+ tildes or supporting both 3+ tildes and 3+ backticks. I ran through the implementations I know of, and Wikipedia's (incomplete) list of implementations (before GitHub went down), and found:

Supports only the 3+ tilde syntax:

• PHP Markdown Extra
• Python Markdown
• Discount
• Pegdown

Supports only the triple backtick syntax:

• ByWord
• Elements
• PEG Markdown Highlight (and derivative Qarkdown)
• R Markdown (only documents triple backtick, but based on Sundown, which supports both)
• markdown-clj
• Showdown

Supports both:

• The CommonMark specification
• Marked App
• Sundown (and derivative Redcarpet)
• GitHub (only documents the triple backtick, but parses both just fine)
• Blackfriday
• Doxygen
• Pandoc
• Parsedown
• Markdown-it

Supports neither, or is unspecified:

• mm2pdf
• peg-markdown and peg-multimarkdown
• MarkdownSharp
• libupskirt
• MarkdownJ
• MarkdownPapers
• Txtmark
• Pagedown
• Dillinger (treats triple backtick code blocks as inline code)

Based on this, I think Stack Exchange should support the tilde syntax, the triple backtick syntax, and the 3+ backtick syntax. Bonus: support of either the tilde syntax or the 3+ backtick syntax should solve the deadkey problem.

The syntax toolbar should continue to indent code with 4 spaces as per the original Markdown spec, or if that's not feasible, it should use the tilde syntax, which has the benefits of being the original version, compatible with GitHub, and marginally more supported by existing implementations.

Answer 4

On Stack Overflow, all the time I'm seeing this happen to people who don't know the syntax.

class Foo {

public static void main(String[] args) {
    // y my code no is working
    Sytem.out.println(qrew3r);
}

}

Some people stop there and never fix it because it's close enough. Others figure out that the first and last lines aren't part of the code block because they're not indented. So they indent those two lines - only those two lines - because the editor doesn't provide an apparent way to indent the whole block.

class Foo {

public static void main(String[] args) {
    // y my code no is working
    Sytem.out.println(qrew3r);
}
}

The result is that we have a site that systematically causes newbs to post questions with poorly-formatted code. Whether or not you like fenced code blocks, when you look at all of the mistakes that users are making, you've got to appreciate that the current UX is broken.

Answer 5

Another reason to include this syntax: Some people are already using it.

However, it makes their posts look kind of strange, since it becomes inline code spread over multiple lines:

This is what it looks like when you put triple backticks above and below multiple lines of text.

By contrast, this is 
a multi-line code block
created by indenting text four spaces.

Answer 6

You can currently specify a language to be syntax-highlighted.

Example:

<!-- language: lang-js -->

    //JS code...

This should not discourage the question, it is even a plus because they don't need to code this feature anymore.

The only thing left to do is to implement the ```` code blocks system (which I believe, is not that hard)

Answer 7

Another major benefit is when marking down code within lists. Creating block codes within list is often a major annoyance, contrast:

- Bullet 1

 Lorem Ipsum (paragraph 1).

 Lorem Ipsum (paragraph 2).

        var foo1 = bar1;
        var foo2 = bar2;
        var foo3 = bar3;

 Lorem Ipsum (paragraph 3).

to:

- Bullet 1

 Lorem Ipsum (paragraph 1).

 Lorem Ipsum (paragraph 2).
```javascript
var foo1 = bar1;
var foo2 = bar2;
var foo3 = bar3;
```

 Lorem Ipsum (paragraph 3).

Bulk of the annoyance comes from the editor not being able to do 8-space indents as CtrlK un-indents instead of converting four spaces to eight. "Also, is that blank gap 7 spaces or 9 spaces?"

Of course, the problem is magnified when trying to put block codes within nested lists. Contrast:

- Bullet 1
 - Bullet 1.1

     Lorem Ipsum (paragraph 1).

     Lorem Ipsum (paragraph 2).

            var foo1 = bar1;
            var foo2 = bar2;
            var foo3 = bar3;

     Lorem Ipsum (paragraph 3).

to:

- Bullet 1
  - Bullet 1.1

   Lorem Ipsum (paragraph 1).

   Lorem Ipsum (paragraph 2).
```javascript
var foo1 = bar1;
var foo2 = bar2;
var foo3 = bar3;
```

   Lorem Ipsum (paragraph 3).

It gets worse with double nested lists. Contrast:

- Bullet 1
 - Bullet 1.1
     - Bullet 1.1.1

         Lorem Ipsum (paragraph 1).

         Lorem Ipsum (paragraph 2).

                var foo1 = bar1;
                var foo2 = bar2;
                var foo3 = bar3;

         Lorem Ipsum (paragraph 3).

to:

- Bullet 1
  - Bullet 1.1
   - Bullet 1.1.1

     Lorem Ipsum (paragraph 1).

     Lorem Ipsum (paragraph 2).
```javascript
var foo1 = bar1;
var foo2 = bar2;
var foo3 = bar3;
```

     Lorem Ipsum (paragraph 3).

Hopefully inserting block codes within list will be less time-consuming after the update.

Answer 8

Another (very) minor benefit is that you can use this syntax to break up code blocks. For example, this code (rendered in an engine) will create three separate blocks with very tight breaks:

```
block1
```
```
block2
```
```
block3
```

I'm not aware of any way to do this using the indent style as unindented lines (no matter how many you interject) don't break the boxes up:

block1





block2


block3

Answer 9

Only drawback I could see is being unclear as to which is the 'right way'. But on a whole I think this would be a great feature to add for someone like me who doesn't want to be using either the button above or spacing in.

Answer 10

The main benefit I see coming from this is that you'll be able to see a little more of the code in the edit box without wrapping. Making it a little easier to specify language is nice too, but I find that the tags take care of it in a large majority of cases.

I'm certainly not opposed, but I don't think it will make fixing code formatting that much easier. You can already select the lines and hit the Code Sample button to add the first level of indent. From there on it's the same amount of work to add additional indents--either copy four spaces and use CTRL-V as a tab key for each line, or copy into editor, fix, and copy back. I think being able to select multiple lines and indent/unindent multiple times would be a lot more helpful than this.

On the downside, ``` would be one of the least intuitive bits of markdown. Doesn't really have the same WYSIWYG feel, at least for me. Using the same sequence to start and end the formatted section could also be a bit confusing, particularly when there are multiple code blocks in a post.

Something like {{{ to start and }}} to end would be clearer, or a custom html tag like, <codeblock></codeblock>, or just allow the <code> tag to span multiple lines to create a block. Or, combine with specifying the language, for example: <java></java>.