Change Linebreak Markup Proposal

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