Should the markdown renderer treat a single line break as <br>?

Question

Inspired by Markdown, One Year Later, a question I think would be better suited to here, than the blog's comment system..

As for #3, "Automatic return-based linebreaks instead of "two spaces at end of line" linebreaks", that’s one I hadn’t considered. In normal Markdown, this:

  Roses are red¶
  Violets are blue¶

Will render like this:

  Roses are red violets are blue 

The Markdown answer is to add two spaces at the end of the line (or a literal <br>, I suppose).

  Roses are red  ¶
  violets are blue¶

Although it’s easy once you know the trick, this is far from intuitive to most. I’m reminded a bit of the double-click mouse problem. I wonder if we should adopt the GitHub linebreak approach here.

Answer 1

This has always been an annoyance with me. When I press the enter key to go to a new line, it would be quite nice if the editor actually did what I wanted it to.

Answer 2

I'll sort of mirror here the post I made on Coding Horror:

---

Hitting the carriage return key on a keyboard should give the user a new line in the output. This is simply typographical common sense.

A markup should not break elementary common sense rules in order to provide other elevated functionality.

The fact users use two carriage returns to create paragraphs [...] is irrelevant. The markup internal rules stipulate that [...] text formatting can break break because the lack of two carriage returns. That's fair enough. But text doesn't lose readability if instead of a new paragraph, every carriage return introduces a line break on the resulting text.

Take a look at the user edit box here:

_{(source: codinghorror.com)}

Is there anything in there that is not clear in terms of formatting? He doesn't use carriage returns and yet his line-break formatting style makes that particular text easy to read and appealing to the eye. The markup however made a mess of it. So, the markup actively ruined the user text. This cannot be.

For the sake of some special formatting elements, like list detection the markup aggressively demands two carriage returns to break a line and doesn't accept the idea of a new-line break, unless the user explicitly forces it with the BR tag.

The line that divides easy-of-use and formatting tyranny can be very thin. On this case it was crossed over. The text the user writes on his text box should have been formatted with single line-breaks. The end result would have been readable text, just like the user intended.

Answer 3

Personally I am completely against this.

Firstly, the other changes (auto-linking bare http://example.com links, no intra-word emphasis a_b_c) don't deviate too far from regular markdown, this does.

The other changes aren't really problems for users of the data-dump, or who are used to markdown else where. The intra-word-emphasis default behaviour should be quite rare, due to the in_line_code formatting, and markdowns ability to escape underscores (yay\_for\_escapes). The non-auto-linked links are a minor annoyance, plus many markdown parsers already have options for auto-linking.

I also think this change will encourage people to try and post code snippets using new lines, rather than the proper 4-space indentation of pre tags.. This will lead to less subtle errors, for example:

Am *def = 456;¶
Ex *abc = *def;

..will become bold, and look broken.. but not not quite broken enough for the user to look at the preview and think, "hmm, I wonder how I post code snippets without it breaking"

Yes, people still post code despite it looking like a mess, but at least it's easy to spot a giant blob of text, and for someone to edit the question and fix up the formatting (something I regular do quite happily)

On the subject of the preview, all the SO markdown modifications this far have been made to SO's markdown engine, but not the preview. The disparity between the showdown.js rendered preview and final output was already a problem, and this will further exacerbate it..

Ignoring all the miscellaneous weirdnesses like this:

• Removed support for intra-word emphasis like_this_example

  This change hasn't be mirrored in the preview (a_b_c shows up at abc in the preview, but a_b_c in the final post)

• Added auto-hyperlink support for http:// URLs in posts

  Nor has this change been mirrored - http://example.com shows up as plain text in the preview, and a link in the final post

Further, I think encouraging people to split text into paragraphs makes their text easier to read. Allowing one-line-break-br's will increase the number of "giant lump of text" questions.

Perhaps the largest issue is: how will questions be migrated to the new markup syntax? This will screw up the display of older post - you can't justswitch to the new markdown() function, not when you can edit old and new posts alike. Say I edit a post that was made with "so-markdown-v1", where new lines are handled the "old" way. I fix a spelling mistake, and click save. Suddenly it's rendered with "so-markdown-v2" and is displayed completely differently.. Another way would be to convert all old posts, removing any new lines not ending in two spaces. This could work, but are you going to do this across all the SO family, and all the StackExchange sites, without introducing any formatting errors?

Finally, I don't think this is a particularly big problem.. There are currently over 330,000 questions on Stackoverflow. Most are perfectly well formatted, most of the others are badly formatted because, well, the author is lazy - lack of any kind of punctuation/formatting, basic spelling mistakes, where the user clearly hasn't re-read their question (I don't mean people who are learning English as a second language, but rather from people who clearly don't care about their question) - such questions would not be helped by turning newlines into <br> tags, as there is no newlines anyway!

I've tidied up lots of badly formatted questions, but I recall seeing very few questions where someone has tried to format their question nicely, but not understood simple markdown syntax, such as two-returns == new paragraph, lists need spacing.. Besides, once they've made the mistake once, it's easy to pickup the solution - put a blank line between chunks of text, just like every book uses to separate paragraphs..

All that said, if this change is made, please do what Github has done - do not call it "Markdown", it's not, call it something distinct, like "Stackoverflow Flavoured Markdown", and mention that clearly next to the input box.

Also, make it internally consistent - if you change the behaviour of newlines in text:

Hi¶
this is my question

..becomes..

Hi
this is my question

Then the same should happen with blockquotes..

> Hi¶
> this is my quoted question

..becomes..

Hi
this is my quoted question

Not like the current markdown:

Hi this is my quoted question

---

Since this post is rather long and rambling, my main concerns are:

• Is this really worth the effort?
• Will the site make it clear it's no longer using standard markdown? (Github does this well)
• Will the alterations be internally consistent? Must act the same in different blocks, including markdown blockquotes, must not require blank lines about lists and code blocks, and be consistent with the WMD preview
• How will questions using the old markdown be migrated, without breaking the formatting of old questions?

Answer 4

Here's an explanation from the Markdown docs.

<h3 id="p">Paragraphs and Line Breaks</h3>

A paragraph is simply one or more consecutive lines of text, separated
by one or more blank lines. (A blank line is any line that looks like a
blank line -- a line containing nothing but spaces or tabs is considered
blank.) Normal paragraphs should not be indented with spaces or tabs.

The implication of the "one or more consecutive lines of text" rule is
that Markdown supports "hard-wrapped" text paragraphs. This differs
significantly from most other text-to-HTML formatters (including Movable
Type's "Convert Line Breaks" option) which translate every line break
character in a paragraph into a `<br />` tag.

When you *do* want to insert a `<br />` break tag using Markdown, you
end a line with two or more spaces, then type return.

Yes, this takes a tad more effort to create a `<br />`, but a simplistic
"every line break is a `<br />`" rule wouldn't work for Markdown.
Markdown's email-style [blockquoting][bq] and multi-paragraph [list items][l]
work best -- and look better -- when you format them with hard breaks.

  [bq]: #blockquote
  [l]:  #list

That's the text before it's converted to HTML. You can read the docs in text or HTML format.

[1]: Here's what the Markdown docs say about line breaks. html: http://daringfireball.net/projects/markdown/syntax.php#p

Answer 5

I am way late to this ball game, but I have to raise a point that I don't think anyone else has mentioned. Markdown behaves this way for a specific reason:

Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. Source: Markdown Philosophy

In other words, Markdown is designed to be equally nicely formatted both as a text document and as an HTML document. That is the reason behind the line break behavior. Markdown documents read nicely as text documents because the author can control the text display without having to depend on the word-wrapping behavior of the editor. This is a feature and by design, not lazy programming as some have suggested.

I, for one, dislike GitHub for making the change they did, because now I have to make a choice between a Markdown document that looks nicely on GitHub and one that looks nicely to someone reading it in a terminal window.

Answer 6

I have a suggestion that might allow everyone to have their cake and eat it too. Leave the parser, but change the editor to add two spaces and a newline when the ENTER key is pressed.

That way code would remain standard Markdown and compatible with every other Markdown parser. Also new posts/edits would be compatible with existing posts.

Answer 7

To answer the question "why can we not treat line breaks in the input as line breaks in the output?"

Suppose hard linebreaks in the input where converted to linebreaks in the output, as many have proposed.

Now, here is the problem: there is no way for me to see the difference between hard linebreaks on the one hand and word wrapping by the editor on the other.

These two paragraphs look the same in the editor:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam venenatis augue
non ipsum dignissim eget posuere nisl porttitor. Vivamus est ligula, aliquam
consequat sodales non, aliquet non nulla.

Nullam interdum tincidunt convallis. Morbi vel pulvinar nisi. Nullam pharetra
sollicitudin libero a vestibulum. Maecenas eget tellus mauris. Phasellus ut
tortor at sapien varius dictum eu in velit.

Because it is only soft wrapped by the editor, the first paragraph would render as:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam venenatis augue non ipsum dignissim eget posuere nisl porttitor. Vivamus est ligula, aliquam consequat sodales non, aliquet non nulla.

While the second paragraph–hard wrapped by the user—would render as:

Nullam interdum tincidunt convallis. Morbi vel pulvinar nisi. Nullam pharetra
sollicitudin libero a vestibulum. Maecenas eget tellus mauris. Phasellus ut
tortor at sapien varius dictum eu in velit.

If I wanted to make the second paragraph look better, I would have to do the backspace-space shuffle for every single line in that paragraph.

(Incidentally, Markdown's usage of two invisible spaces at the end of a line may or may not be called brain dead for the same reason…

If you expect the text to be read in its ASCII form, Markdown's approach is nicer looking than an explicit line break tag like \\ or <br>, but still it is invisible markup.)

Answer 8

I think the "two spaces at the end of a line -> line break" is a weird convention (personally, I'd support getting rid of it and just requiring <br> for this case).

But "blank line between paragraphs" is a decent convention; it's also used in TeX (and friends) which is a pretty good endorsement, IMO.

Answer 9

The non-intuitive line break thing was a problem for me one time. But, then I learned how to correctly do it and haven't had trouble since.

For a tech-oriented site like Stackoverflow I think it is not a problem. However, some users may have a steeper learning curve.

Answer 10

In the context of a text input box, the only reason for the Enter key is for formatting text - it has no purpose otherwise. Why would you purposely ignore a formatting input?

And if the text is being pasted from another source, line breaks and all, is it such a bad thing if it matches the format it had in that other source?

Answer 11

MarkdownSharp does have this option...

http://code.google.com/p/markdownsharp/

like so..

var m = new MarkdownSharp.Markdown();
m.AutoNewLines = true;

string input = "this\nis\na\ntest";
string output = m.Transform(input);

which produces..

input:
this
is
a
test

output:
<p>this<br />
is<br />
a<br />
test</p>

But I don't think we'll be exercising it on the trilogy. Way too many breaking changes from existing content.

Answer 12

Seems like most of those advocating for change assume that messages are typed into a browser window in one pass. Most of those who like it the way it is edit, quote other texts, and use a text editor (i.e., emacs).

Answer 13

Just in case this thread is read when things are to be changed: if anything is changed, then I'd still like <br> to be an exception. For example: I would not mind if both a single and multiple Returns are converted into a single <p>. But I'd not like a single Return to become a <br> like the title suggests.

(I would still be pressing Return twice then, while others might happily use only one. I am not sure if that affects the data dump in any way? Also, old post might look horrible like dbr noted.)

Answer 14

Perhaps allow a raw text entry mode, selected by default, with a switch (either in the user's profile/settings, or on the submission form itself) to use Markdown? More advanced users who want to use Markdown to style their submissions shouldn't have any issue switching, and it allows the less advanced users to use simple WYSIWYG ASCII entry.

Answer 15

Please do that. I'm all for it, but I assume converting the old posts will be a nightmare. Markdown decision is totally absurd in my opinion.

Answer 16

A really confusing design.\
I want \ or other charactors to replace two blanks to change line.\
A visibale charactor is always better.\
Or there need an option so that everyone may use his own style.\
Er.. Is there any easy solution so far?\

Answer 17

Yes. When I press enter, I expect to see a new line just as I would see in this editor. If I wanted a space, I would press space. (I pressed enter after each of these sentences and I just got a space instead of a line break)