There is a proposal on [Talk.Linebreaks] to change the line break markup.

!!!Blog-like

The current approach to line breaks is as follows:

* line breaks inside paragraphs are treated as line breaks (html <BR> tag), except for the last one, that is skipped
* line breaks inside preformatted text blocks are treated as line breaks ("\n" in the html output)
* line breaks inside list items and table cells are not allowed

!!Advantages
* WYSIWYG
* compatible with some blogging software and forums
* obvious way to manually format text (EasyToLearn)
* that's how Microsoft Word does it (hey, countries amended their languages to be compatible with Word)
* doesn't require a change in the current spec

!!Disadvantages
* incompatible with the wiki software
* manually formatted text can't be reformatted automatically
* a chanage of the width of the text results in broken formatting
* text pasted from e-mails or other sources must be reformatted
* single line breaks are InvisibleMarkup
* hard to parse with regular expressions
* inconsistent (text is treted differently in paragraphs and in list items)

!!!Wiki-like

* line breaks inside preformatted text block are treated as line breaks ("\n" in the html output)
* all other line breaks are treated as spaces (also "\n" in the html output)
* additional markup for forcing line break (the html <BR> tag)
* forced line break can be used inside list items, table cells, headings, etc.

!!Advantages
* used by majority of wiki engines (NotNew)
* used in professional typesetting software and in many markup languages (NotNew)
* consistent (new lines are treated the same everywhere, except for the pre blocks -- but that's their function)
* easy to parse, compatible with HTML
* can be automatically reformatted
* can be displayed with any text width, any font on any device
* makes the most common task easy and the rare ones possible (by using the forced newline)
* first step to learning more advanced text processing systems
* forces to use list markup for lists, heading markup for headings, etc.

!!Disadvantages
* not obvious for computer illiterates
* requires additional markup in addresses and poetry
* extends the specification with additional markup for forced line breaks
* requires a change in the current spec