(anonymous guest) (logged out)

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

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Old discussion moved to Talk.Versions.


Please write your opinions of Creole 0.1 here. --Chuck Smith

I think nested lists were not agreed upon. They should go. I also think that the section about preformatted text is ambiguous. It does not differentiate between preformatted and unprocessed, and yet it says that it will work in-line and as a block. But what is preformatted + inline supposed to mean? Clearly whitespace cannot be significant in-line! (One reason being that you cannot nest a pre element inside a p element!)

Which is why Janne & I suggested that triple braces as a block will produce preformatted and unprocessed text (pre element, no processing), where as triple braces inline will produce unprocessed text (span element, no processing).

I think the only other alternative that makes sense is that triple braces inline will produce monospaced & unprocessed text (code or tt element, no processing).

-- AlexSchroeder

We did indeed agree on nested lists about an hour and a half into the workshop and no one opposed them. Nested lists are very useful and we think they should stay.

You are correct about in-line and pre. I made some changes. Does the current state of pre on Creole 0.1 satisfy you?

-- ChuckSmith

If I understand correctly, we now must detect the raw URLs in text and mark them up, right? Good thing there is a ready regular expression for url. But it adds a lot of complexity.

-- RadomirDopieralski, 2006-09-06

How does detecting raw URLs add so much complexity? I mean, even Ward's wiki did it since the beginning from what I remember... --ChuckSmith

It is complex if you want to be correct at all times. Most software just uses some kind of heuristics -- sometimes better, sometimes worse. As the exact solution is rather out of our reach, maybe we should just leave it up to the developers?

Right now I use a simple algorithm: Anything that starts with a protocl name (from a short list) and a colon is treated as url, up to but not including, a space or a punctuation character (like comma or full stop) followed by a space. Or end of line, of course.

But this is not 100% in accordance with the specification, is it?

-- RadomirDopieralski, 2006-09-06

I think that's fine. --ChuckSmith, 2006-09-06

I'm happy with the preformatted stuff. Thanks!

As for nested lists, I'd like to stick to what Lists starts with: "Only one level lists are supported in v0.1 (i.e. no sublevels and no mixed unordered and ordered lists)." -- AlexSchroeder

Oops, I have deleted that now. I meant to erase that before, because multi-level lists were decided upon at WikiSym with no opposition. Well, except for you opposing it now. I also noticed that nested lists even work already on Oddmuse, so I don't really see what the problem is. If you know anyone else who also does not want multi-level lists, we could consider changing it, but all wikis that I know support multi-level lists, so it seems to be a basic feature. --ChuckSmith

Well, Oddmuse only does one particular kind of list; the leading whitespace issue and the use of the dash required new rules on top of the existing ones. Plus mixing bullet and numbered lists raises the kinds of issues that Radomir talked about. Plus nesting could also happen with indentation. MoinMoin uses indentation, and as I said, my plain text files also use indentation, if they use nested lists at all. I also find them to be bad style except for (automatically generated) table of contents information. That's why I don't think it is something to be added lightly to a recommendation. But since it was decided at the workshop, I won't raise the issue again. Sorry for raising it now, in fact. The text on Lists led me astray. -- AlexSchroeder

Personally I'm kind of minimalist, so I'd prefer Creole to be minimalistic too. Limiting lists to one level would surely cut the amount of special cases and unexpected behavior. And would remove the ugliness of the "repeated bullet". Not to mention less complicated parsers and less conflicts with existing wiki markup rules.

I don't really miss them, and think that most of the use cases (apart from maybe TOC) are just hacks to pretty-print a tree structure, which in a wiki belongs rather to the preformatted block or custom syntax.

On the other hand, nested lists are a common feature in wikis and many users rely on them. Creole can afford increased complexity, more work writing the parsers and maybe some conflicts with existing markup. It's just a question of trade off.

Can't really argue with the majority at the WikiSym, especially when I wasn't even there. In the end, I think either way can work. I know I'm biased myself, so I can't really suggest a good decission. I've written wiki more about minimal markup (fixed the link now, sorry).

By the way, funny how there are some efforts with tables (which I consider pretty advanced and rarely used feature), while there is no mention of definition lists or block quotes, which are used on wiki rather extensively (for dialogues).

-- RadomirDopieralski, 2006-09-07

Some comments:

You are specifying "bold" and "italic" markup. This is somewhat against w3c, as they prefer "emphasized" and "strong (emphasized)" meanwhile, without fixing to some specific presentation of that. If you look at it from that perspective, double and triple quotes (semantic markup, as already implemented by many engines) make much more sense than asterisks and slashes for directly addressing "bold" and "italic" presentation.

Lists should work with more natural indentation, not with repeating list markup characters (nobody would do that on paper!).

Unordered lists with "-" are no good, easily confused with negative numbers.

Ordered lists just with "#" are too weak as you maybe want to have more control over enumeration and style. There is a W3C standards problem with that, though.

And OF COURSE we need nested lists.

Headings: not requiring closing ==== is asymmetric, ugly and in some cases ambigue (false positives). It is also irregular compared to other wiki markup principle of using same markup for opening and closing something (like e.g. bold).

A consequence of not requiring the closing === is btw. that you have to use at least two leading equal signs to not get too many false positives (see MediaWiki). If you want to have a clean headline structure, you have to map == to h1. This is bad. Why not just require ^=+ bla bla =+$ (with same amount leading and ending = signs). This is strict enough to not cause false positives and it even looks nicer.

h1 should be = h1h1h1 =, h2 should be == h2h2h2 == of course.

Line breaks: that could be a troublemaker. Backslash at line end for continuations might be natural for some programmers, but not for users. Some people like to have 1 sentence per source line, but result as flowed text.

-- ThomasWaldmann, 2006-09-07

When people write, they think about bold and italic. Their mental model doesn't use strong and em. I don't think it is a problem that we say bold and suggest the use of the strong tag. Unordered lists with "-" are no problem if we require a space after the dash. We might "need" nested lists, but do we need it in Creole 0.1? Of COURSE we don't! Not right here, not right now, not recommended for all wiki engines. We can make leave it out. But I said I didn't want to argue for it anymore. I'm just irritated because of how you phrased it. Asymetric markup is no problem; many other wikis use it (eg. exclamation marks for headings, asterisk for list items). I don't understand "symmetry" as an argument. Some people prefer to use only one H1 per page: The title name of the page. This is not mandated by the HTML standard, but many people (me included) think it is good style. Some people like to have 1 sentence per line, and sometimes I do, but to be honest, I haven't seen any of my users do it. On the contrary, people used to blogging have come used to the idea that a single newline creates a linebreak in the output. That's how the most common word processors work, too. Why alienate them? (Of course, I won't be installing this rule on Emacs Wiki, since Emacs users have different ideas about word wrap, but you get the point. -- AlexSchroeder


I just noticed that this wiki uses CC BY-SA licence. Woudn't this be a lot of problems when we want to publish this spec? I mean tracking down all the contributors to list them is going to be a pita... -- RadomirDopieralski, 2006-09-08

Dirk Riehle suggested this. What would you suggest? -- Christoph 8-Sep-2006


Sorry, my English is not so good. Eble mia remarko ne gravas mondskale, sed mi menciu gxin. Se vi tajpas vikian tekston en cirila skripto por vi estas tre maloportune tajpi krampojn . Cxar en, ekzemple, rusa arangxo de literoj cxe klavaro ne eblas tajpi . Do, vi skribas ruse, sxangxas klavararangxo al la angla, tajpas , sxangxas klavararangxo al la rusa, tajpas titolon de ligilo, sxangxas klavararangxo al la angla, tajpas , sxangxas klavararangxo al la rusa kaj dauxras skribi artikolon. Pro tio en vikimotoroj kiuj estis kreitaj de rusparolantoj eblas krei ligilojn sen , sed per (()). --Aleksandr Sigachov

Cheers for T. Waldmann

I agree with much of what ThomasWaldmann said above. Using "-" and "#" as single-character ways to start a list is generally troublesome, especially allowing for arbitrary whitespace in front of them.

And interpreting linebreaks in wikitext as "br" tags would make much of my cutting and pasting from word processors into a wiki fail.

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 08-Sep-2006 11:49 by 18.85.18.124.