(anonymous guest) (logged out)

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

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 

Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-67) was last changed on 26-Sep-2007 09:44 by ChuckSmith  

This page was created on 09-Jan-2007 20:54 by RadomirDopieralski

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 238 changed one line
I recomend you to read Alains paper "Are Wikis Usable". There's something I would like to add to the [Good Practices] called [MakeTheMachineWorkHarder]. You might be concerned that your parsers become convulted. But the alternative to a usable wiki markup is to write a working WYSIWYG editor, and that's what I call convulted - and IMO wysiwig editors slowed down mankind for much to long.
I recomend you to read Alains paper "Are Wikis Usable". There's something I would like to add to the [Good Practices] called [MakeTheMachineWorkHarder]. You might be concerned that your parsers become convulted. But the alternative to a usable wiki markup is to write a working WYSIWYG editor, and that's what I call convulted - and IMO wysiwyg editors slowed down mankind for much to long.
At line 448 added 80 lines
Being bold, I added Michele's and my own alternative to this proposal. If we are not able to make a decision between Blog-like and Wiki-like line breaks, it is because they are not good choices. *grin*
-- EricChartre, 2007-01-29
Thank you, we need to explore the solution space some more :)
I bolded the points that I'm not sure about or that I don't think I understand fully. Here they are with comments:
* Compatible with most well-written wiki articles (here, WikiPedia, etc.)
** This is a truizm, because you obviously define "well written" as "compatible with this markup" :)
* Compatible with most modern mechanical typewriters.
** As far as my experiences with mechanical typewriters go, the {{{<pre>}}} tag is compatible with them...
* Comfortable for copywriters who can use them to structure the source.
** This is one of the points of ignoring the signle newlines, and your solution doesn't allow this -- because every newline in the source becomes meaningful, so the copywriter cannot use new lines to structure the source the way they think it would make it more readable -- they are left with spaces and tabs only.
* Could make copy and paste easier on some platforms.
** Explain? What paltforms? Copy-paste from what?
* Allows posting text with wrapped lines without the need of additional reformatting,
** ... just creates a million one-line paragraphs which were not present in the original...
* Users have no limited way to express
** You didn't finish this point?
* Could break some ill-formatted articles.
** See the first point. Whatever format we choose, ill-formatted text will break it and well-formed text will be ok -- for the format we choose, of course.
-- RadomirDopieralski, 2007-01-31
I thought about it some more, and maybe it would be easier to find a common ground if we stated the problem that we want solved with the particular change explicitly. Not the "which one is better in general" thing, but what is that one (or several) particular thing that is bad in the established wiki markup that blog-like line breaks fix?
I have basically two problems that (I think) would be solved by changing the Creole's line break handling into wiki-like:
# There is no way to introduce additional, non-meaningful, presentational (for presentation of the raw source, not rendered text) structure in the document raw source, using the line breaks.
This especially affects e-mails and other already formatted, wrapped text, but is also needed for especially long or complicated texts typed directly in the textarea.
# Current syntax encourages sloppy writing, with different style for everyone and no standards for things like lists or headings (both in source and in presentation). Things like "TITLES" and "e m p h a s i s" and "-=(o)=- I like weird bullets".
The first problem could be addressed (with some additional costs) also by some ability to "escape" line breaks, so that they are not meaningful. This increases complexity of the language and still requires special work when including already formatted text. And is non-standard, of course.
The second problem is mainly solved by education of the users and correcting their markup. It can also be helped by chosing certain styles so that the "home-made" formatting sticks out as especially ugly. Introducing "Rules" and forcing the users somehow to abide "The Style Guide" could be also a solution for certain kinds of environments. But I believe that making the "homemade" markup just don't work without additional "yes, I really mean it" syntax is the simplest and most successful solution. Of course, not perfect :).
Sure, you can argue that user freedom is sacred and they have the right to choose -- but what do we need Creole then? :)
PS. It does feel like I'm talking to myself all the time. That'd explain the lack of progress with this issue.
-- RadomirDopieralski, 2007-01-31
Now that we've chosen the wiki-style linebreak handling... probably we should go all the way along the path: we should ignore single linebreaks in list items and headings, and perhaps also those in table cells and quotes (whatever syntax we choose).
-- [[Michele Tomaiuolo]], 2007-02-08
I agree about lists and (potential) quotes, I'm not sure abut headings (but it doesn't really add much complexity, so why not), but tables use the new line differently -- for separating the rows. Any other markup for that would just be artifical.
-- RadomirDopieralski, 2007-02-08
I strongly agree with Michele wrt lists and headings. End-of-lists should be marked with an empty
line. See my [[http://nyctergatis.com/creole/sandbox.creole|implementation]] to experiment. And
I agree with Radomir for tables.
-- [[YvesPiguet]], 2007-02-08
Yes, multiline list and headings maybe useful. As for having a empty line to signify end of the list, does that mean you want tables, headers and horizontal rules allowed in a list item. Eg {{{ <ul><li><table> }}} or would they also end the list?
-- [[JaredWilliams]], 2007-02-08
In my opinion, lists should be as simple as possible. If you need tables etc. inside lists, then you should think about restructuring your document. It's better to use sub-sections and sub-titles in this case.
In fact, for readability at least, shouldn't tables also be followed by an empty line?
-- [[Michele Tomaiuolo]], 2007-02-08
How would you render a table with a line of text immediately following it then? Do we need the distinction?
How do we normally (in books, magazines, posters) recognize the end of a list in cases when there is no indentation?
Personally, I think that allowing tables, paragraphs, headings, pre blocks, etc. in lists opens a Pandora box but doesn't really grant the users much useful power (apart from one use case, where they use numbered lists instead of headings).
-- RadomirDopieralski, 2007-02-08
I'm not advocating headings, rules, and (but I'm less sure there) tables in lists. I mentionned empty lines
because they become necessary when a list is followed by a normal paragraph once you accept multiline
list items. I don't think we should require space (be it empty lines after arrays or space characters after
list stars and sharps) when there isn't any ambiguity.
-- [[YvesPiguet]], 2007-02-08
Version Date Modified Size Author Changes ... Change note
67 26-Sep-2007 09:44 49.696 kB ChuckSmith to previous restore
66 26-Sep-2007 01:47 49.716 kB 63.241.9.240 to previous | to last
65 25-Sep-2007 23:34 49.696 kB RadomirDopieralski to previous | to last restore
64 25-Sep-2007 19:40 49.72 kB 207.44.238.95 to previous | to last
63 01-Mar-2007 09:06 49.696 kB ChristophSauer to previous | to last typo
62 08-Feb-2007 18:29 49.696 kB YvesPiguet to previous | to last No headings and rules in lists
61 08-Feb-2007 18:07 49.284 kB RadomirDopieralski to previous | to last how do we do it in other contexts?
« This page (revision-67) was last changed on 26-Sep-2007 09:44 by ChuckSmith