This isn't exactly a roadmap, but more comments. How could this be formalized to improve our effort here?

We are currently using htmlArea version 3.0 alpha for our blogs. htmlArea SF page

Wysiwyg editing is only available for blogs. Wysiwyg editing of wiki pages and other objects is not currently officially supported.

There is some interest in the Tiki dev arena to move to an xml based format though it's been pushed to the back burner for now.

An related explanation on why from Kristian Koehntopp:

> About mixed html/non html wiki pages. I'm not sure what the solution could
> be. Many wikis don't allow html at all.

Yep. coWiki for example does not allow HTML at all, but stores
Wiki markup internally as XML, so all coWiki pages allow
transformation of the Wiki content into HTML as well as other
formats. Because the coWiki XML markup is a subset of HTML, full
HTML is not possible (but other things become possible).

TikiWiki stores HTML as HTML, and Wiki markup as Wiki markup.
Both are fundamentally incompatible, and overlap in
functionality. That is, even if there is only markp in a Wiki
page that could be rendered using Wiki markup (say bold text),
but this markup is written as HTML (as <b/> tag), it cannot be
preserved by someone not having HTML permissions (because the
bold text is rendered as <b/> in the edit field and subsequently
filtered out).

Conclusion: There must be a property that is part of the page
and that property is "uses HTML". 

A person not having HTML permission cannot create pages using
HTML, and (that is new) edit pages that have the "uses HTML"
property. The latter is necessary because allowing them to edit
pages "using HTML" will destroy the markup in these pages.

Persons having HTML permission can create pag{img src="img/wiki_up/wikiwyg.switch.view.gif" }es using HTML tags
(but only pages actually using HTML get the "uses HTML"
property), and they can edit all pages, if these pages are not
otherwise protected.

Also, that particular incompatibility between HTML and non-HTML
users would be dimished if Tiki would do things similar to
coWiki, that is, store pages as a variant of XHTML and translate
output for edit. HTML users would then get all markup as tags,
always. Non-HTML users would get markup translated into Wiki
syntax, and would be prevented from editing pages that cannot
be translated down into Wiki syntax completely.


UserPagemarclaporte has done quite a bit of research on this.
ysoya has contributed a patch


A 1.6.1 patch for wiki pages is available from ysoya

Competition and standards

This is a nice complete list of Throught the web (TTW)WYSIWYG Editors

The bitflux Editor currently only works with Mozilla or Netscape. We need to monitor it's evolution:

Wysiwyg and Wiki Socialtext
A great review of the issues with wysiwyg inside of wikis at socialtext.
I personally think we should look at ST as leaders because they are dealing with enterprise pressures on the wiki concept (and still dealing with them

Markup Standard
http://www.hexidec.com/ekit.php (java, includes spellcheck)
Interakt's KTML
XStandard (XHTML, ActiveX, Mozilla plugin planned)
http://bitfluxeditor.org (XML, Mozilla)
http://xinha.gogo.co.nz/ htmlarea fork
http://tinymce.moxiecode.com/Tinymce (Javascript - Mozilla, MSIE and FireFox)

Editor Types

XML standards compliant?

JS based

Wikiwyg - Can be used with FF Greasemonkey to happen automatically on any site.
Most interesting feature: allows editor to switch between: wiki markup | wysiwyg | html | Preview modes

Java based


Flash based

CVS Doc section


Please edit this page or post your comment below.

userpageterris: ysoya's demo is nice. Why wasn't it used in Tiki Wiki 1.8? My users' #1 complaint about TikiWiki is the editor. See also EditorDev.

It seems to me that Wikis and BBSs like phpBB, like XML-based content managers, are fundamentally anti-HTML, whether that is DHTML or XHTML. Sometimes this is a GoodThing, for example with the magic you can do by merely beginning a line with !-.

See what I mean?


Unfortunately, a lot of this crazy syntax is like stepping back 20 years. Try to type a left bracket or a left curly brace or a less than sign. Try to enter some XML as if you were writing an XML primer. Where did it go? Well gee, these are special characters in Wiki syntax. How do you escape them? How to you parse Wiki text? etc. This is why SGML, HTML, and XML exist today. It's unfortunate that Ward Cunningham ignored all of this effort in the interst of speed (Wiki). Because what you end with is proprietary text that can only be displayed by one particular Wiki flavor. Existing editors like Dream Weaver and parsers like Xerces can't be hijacked. That is a BadThing. Locking content into one presentation format isn't a good idea in the long run. Some form of XML, like DocBook, is a much better strategy. However, writing XML in a TextArea is very inconvenient, hence the Wiki syntax.

Page last modified on Thursday 10 August 2006 18:31:10 GMT-0000

Upcoming Events