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
http://ysoya.net/tikitest/
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:
http://www.bitfluxeditor.org/
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
http://ross.typepad.com/blog/2006/08/wysiwyg_and_wik.html
Markup Standard
http://richtext.sourceforge.net/
http://vietdev.sourceforge.net/jscript/index.html
http://www.openmymind.net/editor/
http://www.interactivetools.com/products/htmlarea/license.html
http://sourceforge.net/projects/aynhtml
http://www.kevinroth.com/rte/demo.htm
http://www.hexidec.com/ekit.php (java, includes spellcheck)
https://sourceforge.net/projects/fckeditor
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)
WYSIWYG XHTML Editor
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
Please edit this page or post your comment below.
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.