Loading...
 
Skip to main content

Custom Share Module 0.1dev

WysiwygDev

Status/RoadMap


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:

Copy to clipboard
> 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.


TikiTeam

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

Trackers

A 1.6.1 patch for wiki pages is available from ysoya
http://ysoya.net/tikitest/

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:
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

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
Image

Java based

Wikiwizard

Flash based

CVS Doc section



Discussion/participation

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