WYSIWYG editor

For the more technically inclined, Wiki markup is a simple way of formatting a wiki page; it works. However, many would-be users of MediaWiki are put off by what looks to them -- rightly -- to be code of any sort. These users are adjusted to publishing and editing in a more visually straightforward WYSIWYG (What You See Is What You Get) environment.

Rationale
Building WYSIWYG into MediaWiki could be greatly benificial for current users and potential future users. The current editing technique, using HTML TEXTAREAs, can be either the fallback for those with older/text-based browsers or the default for users that prefer the fine level of control of wiki markup. The question of technical feasability to adding a WYSIWYG option could be a blockade to coding it, and here is an introductory look at the technical side of things --

Modern GUI browsers, including Internet Explorer and Mozilla, have built-in functionality to use WYSIWYG editing features; however the means of implementing that functionality varies per browser. Surmounting this obstacle might be greatly aided by any of several impressive open source, cross-browser WYSIWYG editors.

Technical feasability aside, letting users edit in a WYSIWYG input system has a number of advantages:


 * The many would-be MediaWiki users who get scared off by complicated Wiki markup -- not to mention hairy HTML markup -- will have a familiar, word-processor-style interface to work with instead.
 * You can see what an article will look like without previewing it. This will save round-trips to the server.
 * We can use existing spell checkers (although there's a promising native wiki src spell checker (test wiki) with wiktionary- integration in development by archivist)
 * Offline editing (possibly with something similar to Zope External Editor) is much easier
 * It allows easy import for other open source texts and (potentially, with an appropiate script) images with copy&paste.

Conceptual
As noted above, HTML TEXTAREAS could be a fallback for older browsers or those that prefer this for fine control. The WYSIWYG editor could also be limited to reflect only existing wiki markup, with it's democratically decided simplicities and compromises for complexities -- adding nothing to the wiki markup, only providing a more visually straightforward means of changing the markup.

Implementation
There are a few options for making a WYSIWYG editor that works in the browser.


 * 1) Pure DHTML/Javascript. Capture mouse input, buttons, keystrokes, etc., and actually edit the HTML of the current document. It's not trivial, but possible. Epoz 1.0 is an example for this approach.
 * 2) Create a custom browser plug-in, Java applet, ActiveX control. This would probably be workable, but would take quite a bit of hackery, and may or may not work. Requiring users to install any sort of plugin is very undesirable.
 * 3) Both Mozilla and Internet Explorer include a way to make sections of a page editable. IE has the MSHTML Editing Platform, and Mozilla has Midas. Both technologies allow Web developers to make parts of a page editable -- in slightly different ways, of course.

Most current in-browser WYSIWYG editors use this third option. Epoz and HTMLArea, the most prominent ones, are cross-browser - they iron out the subtle differences in the editing API between IE/Moz. This leaves all browsers not based on MSIE or Gecko as non-supported.

Internal Links and Images
http://www.aulinx.de/hilfe/plone/bilder/bildeinfuegen.png

Epoz 0.74 features a great tool box to insert internal links and images. It's based on a search box, images are displayed with thumbnails and can be inserted with a single click. Inserting different image sizes is easy to do by customizing the tool box template. More documentation and screenshots (in german)

HTML to Wiki markup
Leveraging the power of existing html editing/spell checking tools makes it necessary to convert the produced html/xhtml to wiki markup.

If we manage to create a python or php script that converts simplified tidy output (xhtml) to wiki-code, this would be easy to do with epoz. Epoz 0.74 feeds the html through tidy on the server via xml-rpc when switching to source view and on save. This works great, it's Plone's standard editor- i used it to write the Squid document for example. Our conversion script can hook in after tidy, the source visible in 'source view' and submitted to the server would be wiki markup. All without reloading the surrounding page. Creating the conversion script is a challenge, but operating on tidy-cleaned xhtml should simplify matters. Epoz only allows structural markup (no font tags etc), so this is mainly a str_replace. With the appropriate configuration tidy will strip the complex things first.

This setup combines the advantages of both worlds by providing two views switchable back and forth without reloading the page:
 * WYSIWYG view: uses the default css and html editing
 * SOURCE view: WIKI source