| At line 1 changed one line |
| Please see: [[Vote for Line Breaks]] |
| There was a proposal on [Talk.Line breaks] to change the line break markup from the "blog-like" one to the "wiki-like" approach. |
| At line 3 removed 4 lines |
| ---- |
|
| There is a proposal on [Talk.Line breaks] to change the line break markup from the "blog-like" one to the "wiki-like" approach. |
|
| At line 9 changed 2 lines |
| !!!Current Approach |
| requested to be changed, taken from [Creole 0.3] |
| Unofficial poll can be seen at: [[Vote for Line Breaks]] |
| ---- |
| ==Blog-like line breaks== |
| Single line breaks in a paragraph, except for the last one, are converted into a {{{<br>}}} (or equivalent). Double line breaks mark the end of the paragraph. Nobody knows what triple (and more) line breaks do. Line breaks in lists are forbidden except for the end of list items, where they are ignored. Line breaks in tables end rows. Line breaks in preformatted blocks are copied as line breaks. To include a line break in a table cell, use separate markup (like {{{\\}}}). Single line break after a horizontal line, a heading or a placeholder is ignored. |
| ===Advantages=== |
| * Easy to format text exactly the way one likes, |
| * easy to covey a sense of unique style, |
| * all other markup becomes optional, no need to learn it, |
| * Microsoft® Word™ does something that has a similar visual effect. |
| ===Disadvantages=== |
| * Rarely needed with proper writing style: |
| ** for poems, |
| ** for addresses, |
| ** for code. |
| * Complicated to implement: |
| ** hard to detect when an user means {{{<br>}}} and when {{{</p>}}}, |
| ** special cases for ignoring newlines at the beginning or end of blocks like <pre>. |
| * No way to have only one way for introducing <br>, because tables will need separate markup, |
| * impossible to convert automatically into wiki-style markup, |
| * wikis using this will be walled from all other wikis, |
| * copied text requires reformatting: |
| ** when copying from the wiki using this, |
| ** when copying from e-mails, documents, etc. into a wiki using this. |
| * Possible clash with browser's automatic line wrapping, when the browser's window is too narrow, |
| * suggests (encourages) using {{{<br>}}} for layout, |
| * not used in existing wiki engines, |
| * not liked by existing wiki community (with exceptions), |
| * takes the control of page layout and spacing settings from the web designer, |
| * makes the user responsible for spacing and page layout, |
| * makes wiki less accessible for handicapped people, |
| * makes pages look inconsistent where several users contributed, |
| * line breaks are be hard to spot in wrapped text in narrow text areas, |
| * text editors often do automated line wrapping by default, inserting additional line breaks at wrap points, without the user noticing, |
| * users often wrap long lines unconsciously when the cursor reaches the edge of text area, even when they don't mean to end a line, |
| * scanned and OCR-ed text is likely to contain additional line breaks, |
| * e-mail and news posts contain additional line breaks, |
| * not even all blogs use this style, |
| * the blog-style cannot coexist with most wikis' native wiki-style, so mixed-mode is ruled out, |
| * existing wiki community uses wiki-style already, it will be harder for them to accept Creole if it used blog-style line breaks, |
| * some browsers still don't have support for wrapping text in text areas, the feature is not covered by standards, |
| * there is no way to patch all the browsers to play along with Creole, |
| * the markup has to be explained too, and it's harder to explain markup using no visible characters, |
| * it discourages use (and learning) of any other markup, |
| * makes users confuse line breaks with paragraph ends. |
| At line 12 changed 71 lines |
| Treat line breaks as line breaks. Best practice: line continuations made with backslash at end of line. This rule is optional If implementing a mixed native/creole mode. |
|
| Creole: |
| {{{ |
| This is the first line. |
| This is the second line. |
| }}} |
|
| Recommended XHTML: |
| {{{ |
| <p> |
| This is the first line.<br /> |
| This is the second line. |
| </p> |
| }}} |
|
| Sample Output: |
|
| This is the first line.\\ |
| This is the second line. |
|
|
| !!!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 |
| * conflicts with the default rules of 99% wiki engines, making mixed mode impossible |
| * 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 treated 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 |
| * consistent with thedefault ruels of 99% wiki engines, making mixed mode possible |
| * 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 |
| ==Wiki-like line breaks== |
| Single line breaks are treated as spaces everywhere except preformatted blocks. Double (or more) line breaks end paragraphs. In tables, a line break ends a row. To force a line break, use separate markup (like {{{\\}}}). |
| ===Advantages=== |
| * Already in use in practically all wikis, |
| * comfortable for copywriters who can use them to structure the source, |
| * immune to all weird things that happen when using suspicious editors or text processors (like Microsoft® Notepad™ or Microsoft® Word™), |
| * doesn't require a modern browser with line wrapping in text area, |
| * can be easily converted to blog-style new lines when needed, |
| * leave the web designer in control of spacing and layout, |
| * makes it easy to change the layout without editing every page in a wiki, |
| * doesn't require the user to be experienced in typography or arts, |
| * allows the user to just type, without worrying how good the text looks, |
| * makes it easier to handle complicated things, like long urls or complicated plugins, by allowing to put them alone on a line, |
| * makes the source text easier to scan and find relevant fragments, |
| * keeps the paragraphs and line breaks as separate ideas, |
| * allows posting text with wrapped lines without the need of additional reformatting, |
| * makes users familiar with world-wide standards. |
| Disadvantages |
| * Requires a change in the Creole specification, |
| * requires enclosing pasted code, ascii-art, poems and addresses into additional markup (or using forced line break), |
| * users can try to use end-of-paragraph for overriding page layout, |
| * users have limited the way of expressing the unique style of their contributed text, |
| * web designer cannot leave it for the users to decide on the spacing, |
| * users need to learn the markup for the elements they want to use, instead of approximating them with line breaks and indentation, |
| * users can be surprised with the effect if they create their first wiki page without ever looking at and editing existing wiki pages, |
| * spam looks like spam, |
| * tables and preformatted blocks create an exception (but that's what they are for), |
| * list markup spec requires amending to make the line break treatment consistent, |
| * it removes one way of marking a pause in text, forcing the users to use both paragraphs and horizontal lines for that purpose. |
.