Yes, I agree with this practice. This is why I prefer to not use regular expressions for parsing, as the temptation becomes to add requirements to a syntax so it can be parsed unambiguously. Shifting a burden further to the user, and away from the developer.

-- [JaredWilliams], 02-02-2007  

Well, it seems this point more interpreted as [MakeTheDeveloperWorkHarder]. As a developer, I must admit that I do not fully agree with this.
Making the machine work harder makes sense, as long as we have enough computing power, which we probably have. Making the developer work harder is different. On the one hand, the user should get the optimal solution. On the other hand, we must keep the effort reasonable. Keeping the parsing simple helps spreading creole, because more people can easily implement a parser. Complicated parsers also tend to have more bugs. See also about parsing in [[Good Practices]].

The current Creole suggests also to have very forgiving markup. Headings with and without ending equal signs or paragraphs that close bold markup, if the user forgets to close the bold markup himself. Is this really necessary? This is one of the points that make parsing more complicated. And I'm not sure if it is really the best for the user when there are multiple alternatives for the same markup. The more markup can be written in different ways, the more the markup between users will vary. Creole should unify the markup, so there should be only one way of writing headings. Of course headings are only an example.

I still agree that the user should get the best solution, and not the programmer. But we should carefully think whether more freedom in markup is always better for the user. Of course I am biased - as a programmer I am used to follow a special syntax. And normal users may think different. But in the end the user still has to learn how to write headings, or lists, or tables. Optional closing markup does not make it easier for the user. The only reason I see is to make it more compatible to other Wiki engines, but it is still against the goal to unify the markup.

-- [SteffenSchramm], 2007-02-06


The problem is that users will not read specs. The will not read all the exceptions we put in like not allowing space after bullet, or that you have to close a heading with the excat number of equals signs you have at the beginning. People are learning the markup by trying out things. The will save and see what happens. They will maybe save again if it not works on the first try but thats it. If it still don't work they will tell you that markup sucks and all your hard developer work is in vain.

-- [ChristophSauer], 2007-02-06

Christoph, that's not exactly how it is. It's true that users will not usually not read any instructions (there are several ways of encouraging them, but that's irrelevant). But they don't come from outer spaces, you know. Especially on the wikis.

You seem to assume that the users are being caught on the street, seated in front of a computer with an empty editor screen, and told to type in long text with sophisticated markup. This is ridiculous.

* Before editing any page, the users are likely to at least browse other, exisitng pages (rendered).
* The first edit is done on an existing page, with some already formatted text present on it.
* The first edit is most likely to be brief, several lines of text without sophisticated formatting. If the sophisticated formatting is needed, it will be added by other, more experienced users.

The users learn markup by observing it used on the pages (and very rarely, by examining cheat sheets), not by guessing it or by divine intervention. It's impossible to parse markup that is just made up by the user from thin air -- no matter how forgiving the parser is. The only case in which accepting a wide range of markups makes sense is when there actually are several standards requiring specific syntax, and the users are likely to want to use the same syntax on the wiki.

That's why I think that the rules for Creole markup should be:
* obvious from looking at them,
* visually distinctive,
* readable,
* lacking special cases that only appear in some rare contexts (and thus are impossible to learn,
* compatible with existing markups where possible.

I somewhat agree with the "make single person work harder for the benefit of many persons" rule:
* make the spec writer work harder to make developer's work easier,
* make developers work harder to make user's work easier,
* make users work harder to make reader's work easier.

-- RadomirDopieralski, 2007-02-07