No Stupid Questions

There is a theory in UX that says that it is a bad design when it violates the users expectations of how they think it should work. In this case, the interface may not be clear enough about what you're actually typing. You're not typing WYSIWYG text, as you stated in your edit, you are in fact typing source code, or more specifically: markup, in a language punningly called Markdown.

Some of the confusion in the other replies come from your use of the term Carriage Return (CR) which has a very specific meaning to programmers and does not refer to the Return/Enter key. I won't go into that more here, since that's another tangent.

Anyway, Markdown is designed to be a lightweight markup language, so you can focus mostly on content and apply light formatting where needed for emphasis or bolding. As such, it's a good fit for online comments, provided the users are familiar with it, or enough contextual help is available.

Part of Markdown is that it needs two line breaks or two spaces at the end of a line to introduce a forced line break. This is just a choice the creators made of how things should work in Markdown (more on that below). In HTML, for example, you would use <br> instead.

To your question as to why go through that trouble and not just use the newline characters as-is, the most likely reason people prefer it is text editors. By allowing you to break up long passages of text with single line breaks, you don't need to rely on the editor's word-wrap function to keep the full lines visible in your editor.

Markdown is mostly authored more like source code than prose. Moreover, as it is "code", it may be subject to automated reformatting that could impose its own line-length rules, etc. and that would ruin the formatting. This often results in long lines being wrapped twice: at the intended point and the forced breakpoint and it looks terrible.

The original Markdown spec by John Gruber explains it like this:

Paragraphs and Line Breaks

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 tag.

When you do want to insert a 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 , but a simplistic “every line break is a ” rule wouldn’t work for Markdown. Markdown’s email-style blockquoting and multi-paragraph list items work best — and look better — when you format them with hard breaks.

You can argue that that makes it not a good fit for online comment editing, and I would say you have a great point, but it's also very popular and works well for the most common cases. (Especially with programmers because it has many nice features for us.)

Many web apps do allow you to switch between HTML content editing mode (WYSIWYG) and Markdown. I imagine the reason why not more apps do it is just because it's more code to write, test, and maintain.

I usually recommend people learn more about Markdown to avoid being frustrated by the quirks, and maybe even find some handy tricks they didn't already know. On the other side of the screen, as developers, we need to keep in mind that not everyone knows Markdown, and we need to make sure it's obvious to users what it is they are editing and where to find information about it.

So you're talking about Markdown. It's a specific format, popularized initially on Reddit, that has now become so widely used it is almost universal nowadays (and only growing more popular since so many AI seem to use it natively), and while I agree with you in general and I'd even go as far as to call this a fundamental anachronistic design flaw of Markdown, I think to gain any understanding of this issue you have to understand the historical context that Markdown was born from, and for that you need a history lesson.

Let's start by establishing some terminology: "ASCII" is the most basic standard for computerized text. It's quite limited, 127 characters, ~30 of which are non-printable control characters (including CR). This is pretty much the most universal, most compatible form of transmitting text over the internet. It's built into almost every other standard as its foundation, and we basically can't live without it anymore. We often call it "plain text", although nowadays we also have unicode, or "UTF-8" in its most common form, that would also like to claim that title, even unicode contains those original 127 ASCII characters hardcoded right at its base.

Anything beyond pure ASCII or sometimes unicode typically falls under the umbrella of "rich text". "ANSI" was one of the earliest and most basic forms of rich text, again completely built on top of ASCII, and is still used sometimes for terminals today. It allows some basic colors and bold/underline, occasionally supporting double-width or italic. It's very primitive compared to what we are used to nowadays and it relied heavily on non-printable ASCII control codes to do its work. In the old days, there was no capability for any sort of line-spacing other than 1. if you wanted a paragraph, you typically did TWO newlines to add 1 line of extra space in between the paragraphs to make it clear the previous paragraph had ended and a new one was starting.

The first truly cross-platform "rich text" that came around was "HTML", which is still of course what we use for the web today in all its glory. It wanted to do things differently than ANSI, and in a way, this was so that it could be compatible with ANSI. If you're copy-pasting code out of a terminal and getting a whole bunch of hidden non-printable ASCII that are going to mess up your HTML, that's a problem. This is where the roots of that issue you're seeing in Markdown were born. HTML intentionally has a whitespace-agnostic definition. It intentionally wanted to get away from all those ASCII "non-printable" control codes and it consciously chooses to completely ignore them, crucially, including CR/LF (which have all sorts of their own problems with cross-platform implementations, DOS/Windows uses both CR-LF and sometimes only recognizes both CR-LF in that specific order. Unix ONLY uses CR. Older macs ONLY used LF. It was a mess, and it caused a lot of problems (sometimes still does). HTML got around this entirely by completely ignoring those characters and treating them as if they didn't exist. They can't have cross-platform compatibility issues if they don't do anything in the first place.

HTML instead supports tags that control when to move text to a new line, and just as critically, HTML decided to make a key semantic distinction between "lines" and "paragraphs". specifies a line break ONLY, without breaking the paragraph. specifies a paragraph break, or a paragraph block depending how you use it, and that caused confusion of its own. But like it or not, paragraphs quickly became the standard method of laying out text on the web, and was sidelined as an afterthought.

As HTML and the web as whole grew, HTML started to gain a lot of very advanced and powerful features. Early internet forums wanted to make it easy for novices to communicate in some form of rich text without necessarily knowing HTML, and they didn't want to enable all the advanced features of HTML some of which posed legitimate security or usability risks for the rest of the site especially with javascript and web requests. They created their own forms of tagging like BBcode that they translated into a safe subset of HTML behind the scenes. Again it was typical to use paragraphs here, it was starting to become the expectation for "CR" to mean paragraph. Sometimes, the old typesetting definition of paragraphs was adopted, where two CRs meant a new paragraph, and one CR meant a new line only.

Meanwhile, you've got Microsoft Word and other word processors which are also working natively in rich text and paragraphs, and hitting enter in Word gives you a new paragraph, OR a new line depending on exactly what context you're currently in, but again paragraph is kind of the assumed default.

Finally, Markdown enters the scene. It comes from the world of HTML and BBcode and Word, but it wants to go back to the days of ASCII and make invisible choices of whitespace start mattering again, to get rid of all the ugly tags wrapped around all of our rich text up to this point and make nicely readable plain text where the whitespace defines how it's going to be presented, and its choice to resolve this dilemma is that it decides to keep the historical typesetting distinction of two CRs in a row makes a new paragraph, and it translates that into an HTML paragraph so it's not actually separated by two full lines when you have an HTML rendering of markdown, it's a proper HTML paragraph. So far so good. At this point, they could've chosen to do exactly what you said and what I think would've been the consistent thing to do: one CR (not two) means just a single new line, and sensibly, that would translate to an HTML element and everything would've been lovely.

But they didn't.

Instead, for whatever baffling reason, possibly because Markdown does interpret CR/LF in other formatting contexts like headings and tables, possibly because DOS/Unix/Mac line endings were still a bit of problem even at that time, and like I said was very, very sidelined by the whole culture and history of HTML, but without being able to see into their minds I can't say for sure exactly why they decided to go their own way for the implementation, coming up with this wonky "two spaces after a line" to require people to be deliberate about it. But they obviously continued following the HTML tradition of CR/LF being otherwise ignored.

Not to fully excuse this decision, but in their defense, sometimes copy-paste can insert newlines where you don't want them, so it's not always as clear that a CR is intentional the way you're hoping. Maybe the idea was that these non-spaced CRs aren't necessarily going to be intended if you're often copy-pasting long, wrapped lines out of an 80 column terminal or something. I still don't think that is justifiable, but it is what it is.

So, I think I kindof know what you're getting at here, but you're not being very precise about it.

First some definitions (just for purposes of this conversation -- don't take this to be any assertion that a particular term always inherently has a particular meaning, it's just a tool for this conversation specifically):

• Character: a single unicode character.
• Plain text: unicode text absent any formatting.
• Source: the plain text to be fed into a Markdown renderer to produce rendered output.
• Rendered output: the formatted output of a Markdown renderer, as displayed to an end user.
• Editor: any computer program or component of a computer program for the entry of plain text.
• Line: text (plain text or rendered output, depending on context) rendered at the same vertical position.
• Line break: the point at which text (either plain text or rendered output depending on context) starts rendering on the next line because of a newline.
• Newline: a character that always forces a line break in an editor. (Remember "editor" is only about plaintext, so a newline doesn't necessarily force a line break in rendered output.)
• Wrap: the point at which, absent a newline, text starts rendering on the next line due to column width constraints.

(As an aside a line break is sometimes accomplished with a "line feed" character. A "carriage return" character is something else that isn't the same thing. Which is a big part of where the confusion comes from.)

What you're saying, I think, is that putting a single newline in the source doesn't result in a line break in the rendered output. Is that right?

In some editors (Vim being one I know of), when plain text word wraps, pressing "down" when the cursor is on the first line of a wrapped series of lines causes the cursor to jump not to the second line of wrapped text, but to the first line after the next newline. To illustrate:

If this line is wrapped due to
being wider than the available
width.
And if this line is on its own line
due to being immediately preceeded
by a newline.

If your cursor in the above example was on the "w" in the first line there, pressing down would take the cursor to the space immediately before "is" in "And if this line is on its own line".

As a result, it can be quite a pain to deal with word wraps in such editors. This is part of why certain code style guides (like this one and this one have hard limits for how many characters are allowed before the next newline.

Given how much more convenient line breaks can be than word wrapping, people writing source to be rendered into rendered output may wish to be able to insert newlines to cause line breaks in the source without causing any change in the corresponding rendered output.

That all make sense?

At least that's most likely at least one reason why the people who invented Markdown decided specifically to make Markdown work that way.

If you mean here on Lemmy or other markdown based sites, I think the reason is that it would become incoherent in terms of the HTML it generates.

HTML is supposed to be a format that describes meaning, not presentation. The meaning is that Lemmy comments consist of paragraphs (p elements) like any piece of text does. The way to start a new paragraph is to type two newlines in a row.

On occasion text isn't divided into paragraphs, like your example of poetry. The way to represent that meaning in HTML is a br element. You already described how to generate that in Markdown. But that is a rare special case. Makes sense that it requires special syntax so people don't do it accidentally.

Old forum software like phpBB or SMF worked the way you imagine. If I am not mistaken they translated a newline in the BBCode to an HTML br element, unfriendly to screen readers and automated technologies in the ordinary case where text was divided into paragraphs.

Is this a rant about typewriters, computer character encodings, or some computer file format?

Why are you getting files with bare CR characters not followed by a LF? (Is this about last millennium Apple computers?)

CR vs CRLF?

Markdown? https://stackoverflow.com/q/35177253