(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
View Attach Info

Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-23) was last changed on 11-Jan-2007 14:18 by ChuckSmith  

This page was created on 05-Sep-2006 17:10 by Yonat

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 84 changed one line
To break a line ({{{<br /­>}}}), any {{{\s+\\\\\s+}}}} (that's two backslashes ({{{\\}}}) preceded and followed by at least one whitespace) would be sufficient in my opinion. The rendering engine would eliminate theses spaces.
To break a line ({{{<br /­> }}}), any {{{\s+\\\\\s+}}}} (that's two backslashes ({{{\\}}}) preceded and followed by at least one whitespace) would be sufficient in my opinion. The rendering engine would eliminate theses spaces.
At line 97 added 22 lines
Good questions, and I'm glad you asked them, so that we can explicitly substantiate the choices made so far.
I will start with __double newline for separating paragraphs__. This comes from a long tradition of message boards, newsgroups, various
faqs and rfcs, walktroughs and similar text documents -- they are usually preformatted, with single line breaks used merely to fold
the lines of text, and an empty line to separate paragraphs. This "tradition" is also very practical in more formal cases, where you
can use newlines to emphasize the structure of the raw source code,
while keeping the rendering independent -- the "double newline" rule is present in TeX and many markup languages derieved from it.
The textareas used commonly to edit wiki markup are usually very simple and pretty hard to use. Until recently, they didn't even have any support for wrapping the text -- if you had any long lines, you had to scroll. Today's browsers are a //little// better in this regard, but only minimally -- line wrapping is pretty much broken in most of them -- thus providing some means to manually control the flow of text in the source, without impact to the rendering, is still important.
Even if one uses an external editor to edit text -- and there are both special browser plugins or editor scripts allowing to do that -- one's not free from the line-wrapping problems. Many text editors will wrap text by default (which is useful for writing e-mails, for example). You also might need to put on the wiki pages some text taken from e-mails, newsposts, various text files, web pages (some browsers will reformat text when it's copied), or even scanned text. Ignoring sigle newlines allows you to minimize the work with reformatting such text (adding newlines for several paragraphs is always easier than removing them for several hundred lines).
There is also a question of presentation -- with "modern" line-wrapping textareas, a single newline is effectively InvisibleMarkup if it comes near the edge of the editor area. Tracking down and removing such "spurious" newlines is not easy and usually pretty annoying.
As for __treating consecutive whitespace as single space__, it's similar deal. Plus, we don't want people to use spaces to indent or center text -- it's not only ugly and hard to maintain -- it's also totally unportable to devices/software/sites using different fonts and screen widths. Of course, any space at the end of lines should be ignoed because it forms InvisibleMarkup.
Now, as to my propostion of the __forced line break__ markup, it's not really supposed to be a backslash and a space -- rather it's a backslash at the end of the line. The whitespace is added for the reasons mentioned above. Note, that this "fits" with the use of backslash for an escape character -- "eascaped" newline is being treated literally. Using double backslash has the problem of conflicting with the markup of eascaped literal backslash.
I'm think that requiring a newline in the markup for forced line break where possible is a good idea -- it makes the code more WYSIWYG and thus EasyToRead -- you don't need to scan whole line to spot linebreaks -- you only need to look at the actual ends of lines in the raw code. Of course this has a problem if there are places where the newline is forbidden -- I think it's an indication of a greater problem in the markup, though.
-- RadomirDopieralski, 2006-01-03
Version Date Modified Size Author Changes ... Change note
23 11-Jan-2007 14:18 4.467 kB ChuckSmith to previous fixed link to list of line break
22 10-Jan-2007 19:45 4.467 kB RadomirDopieralski to previous | to last my mistake :)
21 10-Jan-2007 19:20 5.191 kB RadomirDopieralski to previous | to last advantages and disadvantages of tilde
« This page (revision-23) was last changed on 11-Jan-2007 14:18 by ChuckSmith