(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-50) was last changed on 30-Jan-2007 14:29 by ChuckSmith  

This page was created on 05-Sep-2006 10:59 by Christoph

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 52 changed one line
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|http://wiki.sheep.art.pl/2006-09-07_wiki] (fixed the link now, sorry).
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|http://wiki.sheep.art.pl/2006-09-07].
At line 58 changed one line
Some comments:
Should // be ignored from parsing only if following "http:" or "ftp:"? The range of TCP/IP schemes is much larger and you can never know what's going to appear in the future. That's why I would prefer generaly to ignore any sequence of "://". --Blahma
At line 60 changed one line
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.
That would rule out any emphasized headings with a colon. My current approach in the moin parser is just to match the URLs (with a whole list of protocols) before the italicss.
-- [RadomirDopieralski], 2006-09-08
At line 62 removed one line
Lists should work with more natural indentation, not with repeating list markup characters (nobody would do that on paper!).
At line 64 changed one line
Unordered lists with "-" are no good, easily confused with negative numbers.
!The case for using asterisk (*) rather than dash (-) for bulleted lists:
At line 66 changed one line
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.
a) dash for bulleted list is not collision free: it collides with ---- for rule when lists are nested 4 deep. It also collides with --- (3 dashes) for rule, which is used by some wikis (including TWiki, which is signing up for Creole).
At line 68 changed one line
And OF COURSE we need nested lists.
b) asterisk for bulleted list is collision free. (Actually I think it was probably the mistaken belief that asterisk for bulleted list would collide with asterisk for bold that caused the decision to use dash). How is the collision avoided? Fairly simply, by using the rule that lists must be of the form: "**<space>list item" and that bold is of the form "**<nospace>bold**". (The possibility of a collision only occurs for lists nested two deep).
At line 70 changed one line
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).
c) The collision is successfully avoided by the five most popular commercial wiki engines with markup ([Confluence], [PBWiki], [Socialtext], [Wikispaces] and StikiPad): they all use * for bulleted lists and either * or ** for bold.
At line 72 changed one line
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.
d) All of the top 10 open source wikis that use * or ** for bold also use * for bulleted lists ([TWiki], DokuWiki and PhpWiki).
At line 74 changed one line
h1 should be = h1h1h1 =, h2 should be == h2h2h2 == of course.
e) * is almost universally used for bulleted lists. Of the 59 wikis on wikimatrix that have markup for bulleted lists indicated, 46 use * and only 3 use -.
At line 76 changed 2 lines
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.
(Sorry my late posting, I've only just stumbled upon this site.)
-- [MartinBudden], 2006-09-10
At line 79 changed one line
-- ThomasWaldmann, 2006-09-07
I also recently found out that dashes will interfere with the {{{--}}} I usually put in front of my signature in wikis.
At line 81 changed 7 lines
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
-- [RadomirDopieralski], 2006-09-10
I've rememberted another minor collision as well, {{{--}}} is sometimes used for emdash.
-- [MartinBudden], 2006-09-11
----
Here some nitpicking by me :-). I know that some of the following points are special cases. However, I think that a good spec should be clear about these cases. Even if the behaviour is intentionally undefined (i.e. implementation-defined), it should at least contain that intention as statement.
First, in the example about pre in lists, the three braces are separated by a space and still recognized as pre! I think this isn't correct (but a restriction from this wiki engine), is it? But then, please put this information in a note.
Furthermore, I would like to see a clean separation between block and inline markup. In the case of pre, the current spec says that it works inline or as a block. However, there is no way to disambiguate both cases at the beginning of a line.\\
My suggestion is to differentiate between both cases as follows: A preformatted block is started by {{&#x7b;&#x7b;&#x7b;}} on its own line. The content of the block starts on the next line, can span multiple lines and is closed by the next {{&#x7d;&#x7d;&#x7d;}} on its own line. On the other hand, inline preformatted text starts immediatly. Hence, it is always followed by some text.
{{{{{{
Preformatted block
~}}}
{{{Inline preformatted text~}}} }}}
My last issue are line breaks. For me, it is not clear whether line breaks are supported in e.g. lists or not?
{{{- Is this a single list item,
or a list item followed by a paragraph?}}}
There is a similar problem with line continuations: For example, the spec is clear that "~[n]o linebreaks are allowed within headings". However, does line breaks here mean physical or logical line breaks (logical=after processing line continuations)? In other words, are line continuations allowed in headings although line breaks are not?
{{{=== Is that a single heading, \
or a heading followed by a paragraph? ===}}}
The section about line breaks and line continuations is not very helpful about that.
I hope I could give some constructive remarks. -- [OliverHorn], 2006-09-10
----
!Comments on use of {{{ {{...}} }}} for image
I'm afraid this is not collision free. {{{ {{...}} }}} is used by MediaWiki for templates. And MediaWiki is the most popular open source wiki, by your charts. Given the widespread use of templates in Wikipedia, I think it would probably be impossible for MediaWiki to adopt this syntax for images.
As an alternative, may I suggest the practice which is commonly used by many wikis, namely augmenting the link syntax with either "image" or "img". I think "img" is preferable, as it is more language-neutral, this leads to the image syntax being: {{{ [[img:foo.jpg]] }}} and {{{ [[img:foo.jpg|title]] }}}
-- [MartinBudden], 2006-09-11
Hi!
(a) It does not matter, and in fact, "img" is a violation of the basic principle of making the markup language-independent. You see, if you see image inclusion as a just a special case of "transclusion", you'll see that templates and images can be embedded using ''the exactly same syntax''. It's just up to the WikiEngine to figure out what the media type is, and include it appropriately. MediaWiki just puts all the images in the "Image:" -namespace, which makes it really easy for MediaWiki to support this.
(b) In fact, I believe this syntax was suggested by BrionWebber, the lead developer of MediaWiki. And if he doesn't think there's a problem, I'm inclined to agree ;-)
-- [JanneJalkanen], 2006-09-11
Yes, it was suggested by BrionVibber. MediaWiki will probably implement Creole in the "Edit Creole" mode, instead of mixed mode. At least that's what Brion had in mind, i think.
-- [Christoph], 11-Sep-2006
In reply to (a) above: my comment was made in accordance with the [goals] stated on this site: the most important goal was being "collision free", whereas the "avoiding Text Tags (principle of I18N)" goal was only 12th in priority.
In reply to (b) above: I should have explained myself more clearly. When I said "...it would probably be impossible for MediaWiki to adopt this syntax..." I did not mean that it would be impossible (or even difficult) to implement. What I meant was that it would be just too confusing for the content writers. I think that, for the average author, it is important to have different syntax for images and templates. I agree that they are both, in some sense, transclusion, but to an author including an image and including a template are different things.
I also think the fact that Brion is thinking of implementing Creole in "Edit Creole" mode supports my case. We should be trying to come up with a syntax that enables all the major wikis to implement in mixed mode (even if they initially choose to implement in "edit creole" mode). I restate my point: using {{{ {{...}} }}} for images would make a mixed mode MediaWiki impractical because it would be too confusing for the authors.
(I've taken the liberty of labeling points made by previous authors (a) and (b), to enable me to more easily comment.)
-- [MartinBudden] 11-Sep-2006
!Clarification of Links syntax requested
The example for a titled internal link is {{{[[MyBigPage|Go to my page]]}}} whereas the example for a titled external link is {{{[[http://www.wikicreole.org/ | Visit the WikiCreole website]]}}} (the external link has spaces around the pipe character). Is this an accidental difference, or does the syntax for the external link require spaces around the pipe?
-- [MartinBudden], 11-Sep-2006
!Anchors
Will Creole have a syntax for anchors?
-- [MartinBudden], 11-Sep-2006
Comment by Max: Isn't this inconsisten with "linebreaks create BR elements"? I think the result should be:
{{{
<ul>
<li>This is a single list item<br />
followed by a paragraph?</li>
</ul>
}}}
No, because a linebreak signals the end of a list item.
-- [Chuck Smith], 18-Sep-2006
! Moving to and from emails
* One criterion I've always considered import is: can I easily copy/paste from and to emails? Two Creole constructs currently fail this test:
** Line breaks: email programs frequently insert line breaks of their own! This would break the wiki markup. Why not use the LaTeX double backslash for line breaks?
** bullet lists: I often see lists written like this (especially by Emacs users) and actually like the WYSIWYG quality it has:
{{{
- this is a list item that spans
several lines
- this is a nested list
This line is not part of the list.
}}}
* I would like to see a minimal markup language. For the more frequently used constructs, ASCII art-like syntax is OK, but for more esoteric commands it makes sense to introduce a uniform macro syntax.
* For our own home-grown wiki syntax, we used a staged translation into a proper abstract syntax tree: The final syntax is nested, much like HTML; i.e., there is clearly defined scope and arbitrary structured blocks can be nested. Before, there is a special translation step that transforms line-centric wiki markup to the block-centric abstract syntax. Advantages:
** I can use our syntax in emails and convert it easily to both HTML and LaTeX (because we have an abstract syntax tree).
** For styled Ajax-based text entry, one needs to convert from HTML to a wiki syntax. A macro syntax permits a very simple solution here: translate HTML tags to macros while keeping the name.
** Reference: "A Wiki as an Extensible RDF Presentation Engine", Rauschmayer, Kammergruber. [http://www.pst.ifi.lmu.de/~rauschma/bib/#rauschma:swemwikked_eswc:2006]
-- [Axel Rauschmayer], 2006-09-19
There is one problem with using indentation to indicate list nesting. Space counting. It's especially annoying when you want to make a nested list and then return to the previous level -- especially if you use indentation large enough to be easily visible. Broken TAB key only adds to the inconvenience.
As for macros, I agree that it's a nice solution to extending wiki markup, but the exact mechanism is usually very engine-dependent. For example, in the [[MoinMoin]] plug-in I re-used the "placeholder" syntax for macros. I'm not sure if it's right, but seems appropriate -- after all the spec doesn't say how you should serialize the object, quoting it raw is also one possible manner of serialization.
The exact method of parsing the raw text is left up to the wiki engine authors. Some wikis use full-blown context-free parsers, other rely almost exclusively on regular expressions, most use some ways of home-brew hybrid solutions. That's ok, as long as the users can use the common markup in all of them (even when there are some occasional artifacts of the parser showing up once in a while).
Maybe there should be a separate page describing the *scope* of this spec?
-- [RadomirDopieralski], 2006-09-19
I'm currently parsing the creole markup at save time, and storing XML (actually subset of XHTML). Then applying the reverse transformation at edit time, XML to Creole. So could implement a specific XMLToEmail transformation.
I think it has a number of advantages. Like sloppy creole markup is corrected, can just embed the XML directly into web pages, and XML to Creole transformation is far easier than the reverse for displaying for editting purposes.
-- [JaredWilliams], 2006-09-20
Radomir: good points, especially about list indentation levels and scope description. I'm really warming up to Creole, it's not easy to go beyond matters of taste.
Two more comments:
//italics//
Why not ~~italics~~? But for me clashing with URIs is not a problem, I don't want free-standing URIs anyway. Only excluding http:// and ftp:// seems a bit limited, though. How about https and mailto?
Line breaks: This is something I cannot live with. Again: I think the LaTeX way (empty lines produce paragraphs, line breaks have to be explicitly introduced via double backslash) of doing this works best, as especially under Unix, programs frequently insert line breaks. I hardly ever use explicit line breaks and thus think that one should explicitly mention them if one really needs them.
-- [Axel Rauschmayer], 2006-09-23
Version Date Modified Size Author Changes ... Change note
50 30-Jan-2007 14:29 17.502 kB ChuckSmith to previous revert spam
49 30-Jan-2007 13:53 0.13 kB 72.232.250.14 to previous | to last Great work! [url=http://hpjijpix.com/bnwk/vsxn.html]My homepage[/url] | [url=http://zlzdzlfh.com/ntuk/yocm.html]Cool site[/url]
48 23-Sep-2006 15:01 17.502 kB 84.150.56.20 to previous | to last
47 23-Sep-2006 13:06 17.501 kB null to previous | to last
46 20-Sep-2006 12:32 16.665 kB Jared Williams to previous | to last
45 19-Sep-2006 22:34 16.172 kB RadomirDopieralski to previous | to last response to Axel
44 19-Sep-2006 21:06 14.946 kB 84.150.32.145 to previous | to last
43 18-Sep-2006 11:36 13.26 kB ChuckSmith to previous | to last replied to Max's comment to discussion page
42 11-Sep-2006 22:09 12.966 kB martinswiki to previous | to last
41 11-Sep-2006 21:54 12.878 kB martinswiki to previous | to last
« This page (revision-50) was last changed on 30-Jan-2007 14:29 by ChuckSmith