(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 345 changed one line
To clarify this: The linebreaks in my Creole implementation are currently just blog-style. It supports mixed markup, but this refers to links, or bold and italic style. By the blog-style filter is now installed here, please check it out. Now to my personal preference: I prefer Wiki-style line breaks. But I don't like the {{{\\}}} line breaks either. My suggestion would be something like.
To clarify this: The linebreaks in my Creole implementation are currently just blog-style. It supports mixed markup, but this refers to links, or bold and italic style. By the way, the blog-style filter is now installed here, please check it out. Now to my personal preference: I prefer Wiki-style line breaks. But I don't like the {{{\\}}} line breaks either. My suggestion would be to support something like.
At line 357 changed one line
Of course the css linebreaks are just a placeholder, it will probably not work with css. Custom markup for such a section could be defined.
Of course the css linebreaks are just a placeholder, it will probably not work with css. Custom markup for such a section could be defined. This would be similar to the [[PreformattedAndNowiki|nowiki/preformatted block]], but would not cause monospaced font or background color change. Note that this is neither a preformatted nor an unprocessed block, but something different. Wiki markup has to be supported in this blocks, its just to switch "treat linebreaks as linebreaks" on.
At line 360 added 168 lines
Either way, I suppose a markup for forced linebreaks is necessary. Otherwise there could be no breaks in list items and table cells.
Anyway, I have a rather personal opinion here, though not very strong. I would prefer to treat single or multiple linebreaks the same way: as //paragraph breaks//. I would leave {{{\\}}} or {{{%%%}}} for generating linebreaks in the output.
The reason for my preference is that, when copying and pasting from Word into a textarea, paragraph breaks are transformed into single linebreaks. Moreover, I guess Word users are already used to break paragraphs with a single "enter". The specs could also explicitly say that both renderings are ok, IMO.
-- [[MicheleTomaiuolo]], 2007-01-23
== Suggestion for a Compromise
Ok, I talked that through once more with Chuck and I would like to suggest this compromise: I think a solution to the issue would be to leave it to the implementers, if they would like to implement bloglike linebreaks or not. Creole should require the least common denominator - wiki style, or how I would call it - //legacy style linebreaks//, since every wiki seems to have copied it from C2/Usemod/Latex. The least common denominator would be to have a forced linebreak syntax {{{\\}}}. That's what all wikis have already. Since creole should be a common markup it is dangerous to introduce a rule which is completely different from what they (we) do right now.
When we created the blog-style proposal we had not enough data, like we have now with the [[List Of Line Break Markup]] and simply decided on what we knew was the least suprise to endusers - we decided from what we knew was usable based on our experience with end user installations. Creoles role should not be to improve markup beyond what is there, the rule of [[NotNew]] is a really important rule. Creole should bring wiki developers together, not divide them. Creole should not pretend to be better than any other markup out there, because it is not better - it is just a common language.
Nevertheless I think that to make markup easy to learn and teach it would be better to have bloglike linebreaks. I don't think that endusers will ever understand the concept of syntactic vinegar. I would like to add to the reccomendation a note that highlights this controversal discussion. The spec should encourage implementers to have a //linebreak option// that accepts //bloglike// and //legacy// styles, although we will not require it. We (the [[i3G Institute]]) will add such an option to the CreolePageFilter for JSPWiki. Therefore the admin/The wiki community should have the option to decide on which mode to run the wiki.
With this in place we will get more experience with communities that are using blogstyle wiki markup. This will make a decission easier in later versions. For now it is more important to get everyone on board.
What do the developers, that already have implemented the blogstyle linebreak, think about this option? (AlexSchroeder, AndreasGohr, MartinBudden, RadomirDopieralski)
[[AlainDesilets|Alain]], as you said once to me: ''WikiMarkup can be used by endusers, but this does not mean that it is usable''. I guess we have to leave it like this for now. For unities sake.
--ChristophSauer, 23-Jan-2007
I'm all for this, thank you for coming up with it. I was going to have that switch (wiki-like/blog-like) in the MoinMoin parser anyways, so I don't mind it at all. It is also a very good idea to have implementation notes and recommendations like this -- for things that are left out of Creole.
-- RadomirDopieralski, 2007-01-23
I wholeheartedly am behind this approach
-- [[Chuck Smith]], 2007-Jan-23
[[PmWiki]] has already supported both interpretations (defaulting to wiki-like), so leaving it up to implementers sounds very reasonable. (PmWiki has philosophically taken the view that this decision is actually better left to individual administrators and authors based on the content, rather than imposing a particular standard.)
-- [[Patrick Michaud]], 2007-01-24
Just a side note, as the best approach depends on the actual user community, the decission should be left to the wiki admins (or communities of the particular wiki site), not the implementers -- developers should try and implement both approaches, with some option for changing them.
-- RadomirDopieralski, 2007-01-24
I am absolutely not in favor of leaving this as a configuration option. Anything that can be configured will be misconfigured. When there is disagreement over the right way to do something, putting in a switch is the easy way out. This tendency has a large part to do with the unusabilty of Unix systems compared with, say, Macs.
[Wikipedia:Darin Adler] told me the way they dealt with these kinds of things at Apple. When an engineer proposes an option, they are forced to choose, and justify, what the default should be. Then, you go back to the question of whether the non-default option is actually needed. According to Darin, and I believe him, most of the time it isn't.
Implementors are, of course, free to vary from the spec. The cost, of course, is reduced interoperability. For some things, like Web protocols, that's a problem, but for linebreaks, people will live. It will just make life less pleasant, that's all.
In the straw poll, we see about a 50-50 split. If implementations follow the same pattern, that about maximizes the probability of problems when cutting and pasting between blogs, and of the user learning experience when contributing to multiple blogs. If we didn't care about those problems, then why bother with a Creole effort at all? Just let each implementor choose the markup language that's best suited to their particular needs.
The arguments against newlines becoming line breaks are clear. First, the probability of unintended linebreaks is high. This is based on empirical evidence: in the blogs that have this behavior, I see them all the time ([example from yesterday|http://atrios.blogspot.com/2007_01_21_atrios_archive.html#116960121787431331]). Second, the long lines make editing painful in many environments other than a textarea with the wrap attribute set to "soft" (which isn't even in current W3C specs, believe it or not). One important such environment is for markup within source code. There are others.
The arguments for newlines becoming line breaks are less compelling to me. First, what is the //real// problem that needs to be solved here. Is it to make it as easy as possible for unsophisticated users to put <br> tags in their markup? Or is the real issue somewhat deeper? After all, there's nothing all that great about <br> itself. It has no real meaning; it's essentially for presentation. So I think it's relevant to ask: are there other, perhaps better, ways of achieving similar presentation goals?
And, to me, the answer is clearly "yes." If you define the problem as the unsightly large vertical gaps between paragraphs, then the obvious solution is to reduce the default paragraph margins (1.33em according to the HTML 4.0 "typical formatting" [stylesheet|http://www.w3.org/TR/REC-CSS2/sample.html]), perhaps adding a text-indent of 1em or so, in line with standard book practice. There are good reasons for the way books are laid out as they are, but I'm inclined to believe that the default large paragraph margins are largely an accident from the early Mosaic implementation.
Another argument I find less than compelling is consistency with Microsoft Word. In fact, the Return key in Word generates a paragraph break, not a line break--the latter is mapped to Shift-Return. Of course, since the default //presentation// of a paragraph break is virtually indistinguishable from a line break, most people don't know the difference. I publish a newsletter where I override these defaults, and I'm constantly having to fix up paragraph vs. linebreak markup. So the linebreak proposal is totally //inconsistent// at the semantic level. (It is, of course, more consistent at the purely presentation level with default settings, because HTML <br> looks just like a Word paragraph break, and HTML <p> looks just like two Word paragraph breaks in a row, but as with anything presentational, that illusion of consistency goes away when you change the stylesheets from the defaults).
I am not arguing that the <br> tag should disappear. I am, rather, arguing that it should be a conscious choice on the part of the author, that they should learn to type {{{\\}}} when they want it. It's relatively rare markup and arguably should be even rarer (especially if we have bulletless lists, which I'm increasingly thinking are a good thing). Therefore, it does not deserve to be mapped to the second-biggest key on the keyboard. And I am also arguing that coming to agreement would ultimately be very beneficial to users, as opposed to encouraging implementors to do their own incompatible things.
So I cannot agree to the compromise currently under consideration. At the very least, I think we need to go through the exercise of deciding which should be the default.
-- [[RaphLevien]], 2007-01-24
Ok, so that'd take us back to square zero. Raph, do you have a proposition of a process that could allow us to make any progress? Discussion doesn't help here, I can see a fundamental difference in the point of view of participants.
I think that testing is one way of researching this kind of doubts. But we won't get to test it on real wikis with real users until we have a working wiki with both options available.
I agree with you that options in the final product are not to be taken lightly. But I also see that Creole is being planned for two totally different use cases -- you can't make a program that creates both hard links and symbolic links, like "{{{ln}}}" without introducing an option to tell it what to do, like "{{{-s}}}". Guessing will only lead to irritation. Agreed, in such a case one usually just makes two separate applications, tuned for the separate, different use cases. But we don't have resources for that.
At the same time, I'm pretty sure that any kind of polling among the developers won't solve this kind of technical problem. Polling can be a good way to collect user feedback or divide a community, but not for making this kind of decissions.
This discussion became too long to follow and understand already, and we start to repeat ourselves. I think we should create two summaries on the actual proposal page, descriping the points of view of both "sides" of the argument.
-- RadomirDopieralski, 2007-01-24
I agree with both of you: 1. Making something an option is a sign of faulty design. 2. Discussion is not going to carry us further. Personally, I'm in favor of not specifying it. Not now, maybe later, maybe not at all. ExtensibleByOmission. We're just not going to say anything at all.
-- AlexSchroeder
I edited the [ChangeLinebreakMarkupProposal], trying to summarize our discussion. I made up some advantages of blog-like approach, but they are probabbly ill-written and only few. That's because I could find any arguments here apart from "some blogs do that" and "this must be obviously easier". That's why I want to ask you to amend that list. Please be bold, and don't hesitate adding advantages and disadvantages, and also marking the points you think are untrue or exaggerated -- and discussing them here.
__As this stands now, it's probably very one-sided and deformed summary.__ That's because I want to encourage the other side of the discussion to participate a little more.
-- RadomirDopieralski, 2007-01-26
Ascii-art needs pre tags anyway to have fixed-width characters, doesn't it?
-- YvesPiguet, 2007-01-26
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