Introduction

One of the major obstacles to implementing an off the shelf browser based rich editor, is the difficulties involved in "round-tripping" the content (losslessly converting from html to moin markup, see HtmlConverter). An alternative to using a wiki markup language as the native format in which files are stored would be to use HTML.

Motivation

This would be most valuable inside a corporate environment, or on a wiki with a closed userbase. As we have seen from the Internet and email, a fully html wiki would be a security nightmare, as well as offering additional opportunities for spammers to include content in open wikis.

But many organizations are finding wikis invaluable for sharing information internally. Wiki markup is becoming a major obstacle however, as beginning users cringe from an interface that doesn't involve pointing and clicking, and advanced users complain about the restrictions imposed by wiki markup.

Implementation

Display

Pages would be stored in html format, and much like the current implementation, would be processed to expand macros, add themes, etc. The major difference would be the removal of the wiki markup to html conversion step.

Editing

Users would be given the choice of editing the raw html, using a browser based WYSIWYG editor, or uploading an existing document.

CamelCase and Autolinking

One of the fundamental features of a wiki is the simple linking capability, usually by automatically linking words in mixed case to other wiki pages bearing the same title. This behavior should be preserved, either by modifying the WYSIWYG editor to autolink according to the wiki rules, or when it currently occurs, while generating the page for display.

Limiting HTML tags

One thing that might help reduce the security issues, as well as keep pages from becoming a design nightmare, would be to limit the allowed html tags to basic formatting commands. Public forums do this, for example. And advance option might be to create a permission to control the ability to use the full set of html tags.

Advantages

• Would simplify the integration of an existing WYSIWYG editor
• Allows existing html content to be directly imported
• Allows users to use their choice of editors to create content.

Disadvantage

• Would require modifications to the codebase.

  • Bypass the html -> moin markup on save

  • Bypass the moin -> html on display (but still perform CamelCase autolinking and macro processing)

  • Some macros would need to be updated (such as TableOfContents)

• Some people would prefer to use wiki markup over both WYSIWYG and raw html
• The diff feature might require a change of algorithm to work properly (an alternative might be to "tidy" the html before saving to disk)

Discussion

Obviously this is wouldn not be a trival change to MoinMoin. In fact, this would arguably be a completely different program than MoinMoin. But this should be discussed, even if only to determine that this is a bad idea With the proliferation of more advanced browser based editing solutions, more people are going to ask this question.

• We might soon have a GUI editor (html based) which output is converted back to wiki markup. So just be patient. -- ThomasWaldmann 2005-07-10 09:57:13

  • I can see that there is a lot of movement in that direction, I'm just wondering: if pages are edited as html, and displayed as html, then what purpose does wiki markup serve? That's my fundemental question. I always thought that wiki markup was created so that people didn't have to learn html, but a WYSIWYG editor serves the same purpose. What would be the advantage would there be in translating pages to and from wiki markup for persistance, rather than storing pages in what would seem to be their native formats? -- ChrisAkre

    • Just see the list under headline "Disadvantages".

      • I see the list under "Disadvantages" (I wrote the list) but I guess I was hoping for more of a "No, the disadvantages outweigh the advantages becuase you forgot about xxx" kind of discussion. I mean to me, the choice of editors, the import of content, and the simplification of WYSIWIG integration are major wins, and the disadvanges seem to pale in comparison. --ChrisAkre

  Some input from someone in a corporate environment. I'd love to use MoinMoin for installation documentation. The biggest hurdles are distributing the information to customers. Once I've built the document, we often need to send documentation via CD or ftp or email. I haven't found an easy way to get a distributable version out to customers. Another advantage of WYSIWYG editor would be image embedding. With Microsoft Word I can put screen shots in the install document with a copy-and-paste but with the current editing features of MoinMoin I have 1) save the image to a file, 2) attach the file, 3) save the page. --BrianBrooks

  • You can easily use formatters to output pages to e.g. PDF. See FormatterMarket. There is moin-dump script that create plain html form selected pages or the whole wiki. Its installed your prefix/bin.

CategoryUsabilityObservation