WikiCreole 1.0 Spec Official!
WikiCreole is an attempt at standardizing wiki-text. I had heard of it a while back, but figured it wouldn’t go anywhere since wiki-text is destined for obsolescence. Yet, somehow, the WikiCreole group pushed ahead and has now published its 1.0 spec. While I appreciate this attempt to standardize wiki-text, which differs wildly from wiki to wiki I have to say: WikiCreole is an exercise in futility. There is already a wonderful mark-up language called HTML and it has a wonderful layout and styling facility called CSS. The problem that WikiCreole is addressing is one that doesn’t exist anymore: the ability to create formatted text in the browser. Now we have a healthy choice of good WYSIWYG editors, including Xinha, TinyMCE, FCKeditor, and others.
Truth be told, the real culprit isn’t WikiCreole, but the archaic wiki engines that still rely on wiki-text. Deki Wiki was built with an XML page processing engine since the get go. It allowed us to leap over this whole wiki-text nonsense and immediately integrate with all other systems that use HTML as their representation (i.e. the rest of the Internet). With our mesmerizing adoption growth, it appears we made the right decision. 
Nov 16th, 2007 at 4:41 pm
I think one serious limitation of current WYSIWYG editors for (X)HTML is that they typically try to mimic the worst features of dinosaur applications like MS Word. So you find really complicated interfaces, and a focus on presentational formatting.
That said, of course, there’s no reason I see that these interfaces couldn’t support more semantic authoring and cleaner interfaces. But I think until we see this, more direct markup has its place.
Nov 16th, 2007 at 5:08 pm
I would argue that it’s more likely that rich semantic information can more easily be associated with content when the editor has a higher degree of interactivity. Think context sensitive menus and hints. These are features that streamline the user experience and enable a more efficient form of data manipulation. Any text-based input method will have to resort to codes and notations to achieve the same. I doubt that will go over well with the majority of users. Hence, my lack of faith in the future of wiki-text.
Jun 2nd, 2008 at 1:00 am
Whilst a wizy-wig editor is a great idea, you fundamentally have missed the point of a wiki which is that it is human understandable markup.
The point of having markup is that it is not HTML, because HTML isn’t a standard it is a series of options. Take e.g. the simple question of how to tell the browser to break a block of text at a point if the line is too long. All browsers but IE accept but apparently it isn’t W3C compliant. is compliant but not accepted by firefox version 2.
The point about markup is that the meaning can be tightly defined (irrespective of what Bill Gates decides) and then the HTML can be made to reflect the meaning on the total hash of browsers we now have.
Moreover there are other issues such as security whereby any decent application will need to have to have direct access to the raw text (that outside the markup/formatting) and the closer the markup is to HTML, the more difficult is the problem of checking for security backdoors.
Jun 2nd, 2008 at 1:02 am
Oh dear, it appears my references to “& s h y” and “” have been interpreted as HTML rather than as text which is exactly the kind of problem that happens if you accept HTML input rather than markup!
Jun 2nd, 2008 at 1:04 am
Oh f*ck, it should say … [GT]wbr[lt]
Exactly why there is a need for a common standard markup …. more to define what is not part of the standard than what is!
Jun 2nd, 2008 at 1:25 am
Insomnia, your argument simply doesn’t hold. Look at all the wikitext-based engines and their totally absurd notation for embedding rich content. Eventually, you will end up exactly where you started and that is with a general purpose markup language. So, to me, wikitext standardization smells of NIH. Just put it to rest, let it go, and come back to the fold of standardized markup so we can all make real progress. In my opinion, wikitext is dead.