WYSIWYG editor: Difference between revisions

From Meta, a Wikimedia project coordination wiki
Content deleted Content added
mNo edit summary
 
(25 intermediate revisions by 24 users not shown)
Line 1: Line 1:
{{MovedToMediaWiki|WYSIWYG editor}}
{{MoveToMediaWiki}}
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.

The acronym ''WYSIWYG'' is most often used, but in the case of mediawiki, this is false, you can never get exactly what you see, since what you get depends on your browser, screen resolution, fonts, your mediawiki skin and so on. WYSIWYM (''What You See Is What You Mean'') is more precise but rare.


==State of WYSIWYG and WikiMedia==
Presently there is no available 'ready-to-go' package for incorporating full WYSIWYG into the WikiMedia software.

==Design==

===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 its 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.

#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. 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 (most notably Opera and KHTML (backend used by Konqueror and Apple's Safari browser)) as non-supported.
#: I'm working with [[FCKeditor]] which supports last versions of Opera and (afaik) KHTMl too. If you feel interested to see the results of my integration - contact me. --[[User:Shtriter|Shtriter]] 07:20, 26 July 2006 (UTC)
#:: FCKeditor doesn't work in Opera 9.02 (latest version as of now) --[[User:Amikortol|Amikortol]] 23:00, 2 October 2006 (UTC)
#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.
#: Imho, limited approach. Only Java applet is (possibly) cross-browser compatible. But not all users have Java on their machines and JavaScript is supported by all popular browsers (well, maybe except text-based, but I think that Java wouldn't work there too)... --[[User:Shtriter|Shtriter]] 07:20, 26 July 2006 (UTC)
#Both Mozilla and Internet Explorer include a way to make sections of a page editable. IE has the [http://msdn.microsoft.com/library/en-us/dnmshtml/html/mshtmleditplatf.asp MSHTML Editing Platform], and Mozilla has its [http://www.mozilla.org/editor/midas-spec.html Rich Text Editing API]. 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 the third option.

===Proof of concept: WYSIWYG Editors ===

====FCKeditor====


An experimental implementation of [http://www.fckeditor.net FCKeditor] into MediaWiki 1.7.1 is described [[FCKeditor|here]] which converts your input into HTML. A version based on 1.5.3 can be downloaded from [http://developer.berlios.de/projects/enotifwiki here].

Another implementation using HTML::WikiConverter is described at [[FCKeditor and HTML::WikiConverter]].

====TinyMCE====

You can also download the following patch: [http://www.logicsupply.com/pub/wysiwyg.patch.zip http://www.logicsupply.com/pub/wysiwyg.patch.zip]. This patch integrates [http://tinymce.moxiecode.com/ TinyMCE] into MediaWiki version 1.5.7. The TinyMCE source is included in the patch. I've added an option to the user preferences to enable or disable the editor on a per user basis. All HTML is converted to appropriate wiki markup before previewing/saving.

Limitations include:

* Links and images must still be specified using wiki markup
* Preformatted text (lines starting with whitespace) doesn't survive the trip to and from HTML
* Some features, like underline and strikethrough, have no effect.

If someone wants to hack TinyMCE to make these features work, they're more than welcome.

For details on implementing TinyMCE see the article on [[TinyMCE]].

====Mozile====

[http://mozile.mozdev.org Mozile] takes a different approach to editing, using [[Wikipedia:Document Object Model]] operations instead of the [http://www.mozilla.org/editor/midas-spec.html designMode] features which most other editors rely on. It also supports structured editing based on [[Wikipedia:RelaxNG]]. A [http://mozile.mozdev.org/0.8/demos/mediawiki.html MediaWiki editing demo] is available which makes use of the html2wiki.xsl tool mentioned below.

==== wikEd ====

[[w:User:Cacycle/wikEd|wikEd]] is a full featured JavaScript rich-text in-browser editor for Mozilla-based browsers that integrates into MediaWiki edit pages. wikEd keeps the wikicode text but adds character formatting and wikicode syntax highlighting. It also lets you manipulate the text like in a real word processor. Features include:

* Pasting formatted text, e.g. from MS-Word (including tables), wiki pages, and web pages
* Converting the formatted text to wikicode
* Wikicode syntax highlighting
* Regular expression search and replace
* Server-independent ''Show preview'' and ''Show changes''
* Single-click fixing of common mistakes
* History for summary, search, and replace fields

==== Other Wiki engines/services that have WYSIWYM ====

Try out the editing feature on these sites, for some inspiration.

http://moinmoin.wikiwikiweb.de - Open source wiki engine (competitor to MediaWiki)

http://www.wikispaces.com - hosted wikis only, no software download

http://wetpaint.com/ - hosted wikis only, no software download

http://twiki.org/ - Open source wiki engine

http://www.netcipia.net - wiki farm, hosted wikis only, no software download.

http://www.jspwiki.org/wiki/WikiWizard - Open source wiki engine (click Edit and then choose editor WikiWizard to see how it works).

See also [[Wikipedia:Comparison of wiki farms]], which mentions several wiki farms with WYSIWYG.

===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. [http://www.aulinx.de/hilfe/plone/bilder/ 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 [http://plone.org Plone]'s standard editor- I used it to write the [http://www.aulinx.de/oss/code/wikipedia/ 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


:That's great! But I wonder again, why only server-side scripts? I believe that it would be better to do it on client-side and let the user to switch between the views dynamically. There is already very limited but working prototype for it. For further information - contact me. --[[User:Shtriter|Shtriter]] 07:20, 26 July 2006 (UTC)


An XSLT stylesheet for converting HTML to wiki markup is now available: [http://mozile.mozdev.org/0.8/demos/html2wiki.xsl html2wiki.xsl]. It is still a work in progress but it can handle a wide range of formatting.

Advantages:
* XSLT can be used client-side by most modern browsers.
* The resulting wiki markup can be submitted as if it came from an HTML textarea.

Disadvantages:
* Much of the white space information is lost during parsing and the XSL transformation.
* The current MediaWiki parser does not provide enough information about templates and other generated content in an article's HTML.

Any HTML to wiki markup conversion tool will need more information about the generated content than the MediaWiki parser currently includes in the HTML which it generates. Otherwise it will have to interpret templates as normal content, for example, when they should be converted to the <nowiki>{{Template}}</nowiki> syntax. The most direct solution to this problem is to make the parser include more information. In large part this would simply require better use of the "class" attribute. Sometimes it would require adding elements to wrap the generated content.

Proposed changes to the parser:
* The &lt;nowiki&gt; tag should become &lt;p class="nowiki"&gt;.
* Container &lt;div&gt; elements for images should distinguish between the "thumb" class for thumbnails and the "frame" class for frames, even if the CSS for the two classes is the same. The containers for scaled images (those with their size property set) should be marked with a "scaled" class.
* Templates (but not nested templates) need to be marked as such in the HTML.
<pre>{{Template name}}</pre>
should become
<pre>&lt;span class="template"&gt;
&lt;span class="template-name"&gt;Template name&lt;/span&gt;
Expanded template...
&lt;/span&gt;</pre>
The "template-name" class can be marked as <code>display: none</code> in CSS.
* References need to include their content at the reference point.
<pre>&lt;ref&gt;Reference content.&lt;/ref&gt;</pre>
should become
<pre>&lt;sup class="reference"&gt;
&lt;span class="reference-content"&gt;Reference content.&lt;/span&gt;
Reference links and number...
&lt;/span&gt;</pre>
The "reference-content" class can be marked as <code>display: none</code> in CSS.
* Category links need to be included in the HTML.
<pre>{{Category:Category name}}</pre>
should become
<pre>&lt;span class="category-link"&gt;Category name&lt;/span&gt;</pre>
The "category-link" class can be marked as <code>display: none</code> in CSS.

The use of new elements with CSS <code>display: none</code> is in the spirit of adding semantic structure. It would be possible to use comment tags instead, in order to provide better support for legacy browsers.

===Possible problems===

Things which need to be worked around include:
# An editor should support the user in getting a headline right instead of using a big font, marking a citation instead of italicizing text, and so on. Imho most wysiwyg-editors lures people away from thinking about the meaning, and this is wrong. -- [[User:D|∂]] 01:47, 6 August 2006 (UTC)
# Displaying differences between <i>italics</i> and ''emphasis'', <b>bold</b> and '''strong emphasis'''. Italics and bold are only used for articles on typesetting. (Technically mathematical formulae should use &lt;var&gt; but probably people are using &lt;i&gt; as it is shorter.)
#: Mediawiki originally interpreted ''double apostrophes'' as emphasis and '''triple apostrophes''' as strong, but this has been changed to italics and bold. We should probably get the developers to make up their minds before we start worrying about how a WYSIWYG editor implements it... — [[User:Omegatron|Omegatron]] 22:04, 14 December 2006 (UTC)
# Displaying formulae and potentially also music, maps, timelines, chess... allow editing?
#: Perhaps MathML supporting browsers will be able to edit formulae
#: There is ajax Math Preview. The sourse code was [http://aluno.no-ip.info/juca/mw-AjaxMathPreview-idea.diff here]. For more info - google in Mediawiki-l maillist. --[[User:Shtriter|Shtriter]] 07:19, 26 July 2006 (UTC)
# Displaying templates and allowing editing and inclusion of templates
#: What about protected templates in a non-protected page? (Other similar combinations...)
#: I have an idea. It would show up as a square box with the template name inside, and upon double-clicking a new tab would open (between the text box and formatting buttons) and allow editing of that template. This is a bit like handling of OLE objects in Microsoft Office.
#: I'm working over it on [[en:User:Pilaf/InstaView/Devel]] --[[User:Shtriter|Shtriter]] 07:19, 26 July 2006 (UTC)
# Allow easy input other tags such as <s>strikethrough</s>, often used off the article namespace?
#: No problem. [[FCKeditor]] even allows to insert images without any difficulties!
#: Or do you want the <del>delete</del> tag? Maybe we could restrict which buttons were displayed in which namespace to discourage certain tags from being used in the main article namespace? — [[User:Omegatron|Omegatron]] 22:11, 14 December 2006 (UTC)
# Displaying category links, interlanguage links?
#: Same as MW do? I'm working over it on [[en:User:Pilaf/InstaView/Devel]] --[[User:Shtriter|Shtriter]] 07:19, 26 July 2006 (UTC)
# Over-use of color, size, and other features. See MySpace.com profiles for examples of people with no design knowlege let loose.
#: Any suggestions? Prohibit color editing? Or at list for not registered users? --[[User:Shtriter|Shtriter]] 07:19, 26 July 2006 (UTC)
#: Seriously. As soon as we implement this the site will turn into Myspace if we don't limit what the interface can do. It should only be capable of the things that the standard toolbar is capable of. Users shouldn't be allowed to change fonts, colors or create big bold text for headers, for instance. If they want to do things like that for special cases, they should be forced to use the source code editor. — [[User:Omegatron|Omegatron]] 22:08, 14 December 2006 (UTC)
# Issues with users cutting and pasting from word processing software especially Microsoft Word. This results in non-compliant HTML and could be rendered incorrectly (if at all) from non microsoft platforms.
#: We can have it strip anything except basic markup, but we'd have to incorporate a list in the software to indicate what "basic" means. — [[User:Omegatron|Omegatron]] 22:09, 14 December 2006 (UTC)

==Wikipedia-WYSIWYG-Editors not running inside the browser==
* You can find a Wikipedia-WYSIWYG-extension for Emacs here: [http://en.wikipedia.org/wiki/Wikipedia:Text_editor_support#GNU_Emacs Wikipedia:Text_editor_support#GNU_Emacs]

Other text-editors are covered in [[Wikipedia:Text_editor_support]], too.

==External links==

*[[wclEditor]] - A combination of [[FCKeditor]] and a set of useful js. Allows dynamic switching between original editing and WYSIWYG and even more...
*[http://www.GeniiSoft.com/showcase.nsf/WebEditors List of all WYSIWYG editors]. Table info about almost all WYSIWYG editors on the net.
*[http://wikimania2006.wikimedia.org/wiki/Proceedings:CS1 WYSIWIKI - Questioning WISIWIG in the Internet Age]
*[http://www.themaninblue.com/experiment/widgEditor/ widgEditor]. New! Small (32Kb) WYSIWYG editor where HTML can be swapped for wiki markup. Promising.
*[http://www.high-beyond.com/perspective.aspx?action=edit-form&page=sandbox.ThisIsATest A WYSIWYG editor] at an existing wiki, opened to a test page.
*[http://www.seedwiki.com/wiki/exterior_design_committee/landscaping_and_greenspace.cfm?edit=yesi=92 another WYSIWYG editor] at a commercial "wiki farm" [http://www.seedwiki.com (www.seedwiki.com)], opened to an existing page. Uses unmodified FCKeditor - may be converting back to wikitext.
*[http://www.zope.org/Members/mjablonski/Epoz Epoz 0.74] is a cross-browser WYSIWYG editor for [http://www.zope.org/ Zope], with xhtml cleanup (tidy via xml-rpc), source view, works with IE5.5+ and Mozilla, falls back to textarea otherwise. Uses Rich Text Editing API on moz. [http://www.zfl.uni-bielefeld.de/personal/mjablonski/epoz/ Demo]- switch to source view with the checkbox in the bottom left corner
* Epoz NG (1.0), (now called [http://kupu.oscom.org/ Kupu]) - next generation based on a different concept, currently under heavy development. Features native xhtml, async saving, propably xslt...
*[http://www.fckeditor.net/ FCKeditor]
*[http://www.dynarch.com/htmlarea/ HTMLArea 3] - works with IE5.5+ and Mozilla, falls back to textarea otherwise ("we have to inform you that we no longer actively maintain HTMLArea").
*[http://www.uwa.edu.au/students/__squizlib/htmlarea/htmlarea-prod/ Alternate site]) is a BSD-licensed, cross-browser WYSIWYG editor. There's a good [http://dynarch.com/mishoo/htmlarea.epl demo]. Also features a spell checker plugin potentially useful for Epoz ([http://www.uwa.edu.au/students/__squizlib/htmlarea/htmlarea-prod/examples/spell-checker.html Demo]).
*[[Wiki:WysiwygWiki]] has some more links and discussion.
*[http://wikifeatures.wiki.taoriver.net/moin.cgi/WysiwygEditor WysiwygEdit] on [http://wikifeatures.wiki.taoriver.net/moin.cgi/FrontPage WikiFeatures] (one working htmlarea demo, no wiki src editing)
*[http://www.mozilla.org/editor/midas-spec.html Rich Text Editing API] is Mozilla's built-in WYSIWYG editor, the equivalent of IE5.5+'s 'Rich Text Editor'. There's a [http://www.mozilla.org/editor/midasdemo/ demo]. Most Editors are based on these two mostly compatible editing APIs.
*[http://richtext.cs.ramesys.com/ Richtext Editor]. Has lot of tools like "Insert Special Characters". IE only. [http://richtext.cs.ramesys.com/rt-0.3/help/samples/test_embedded.asp Demo]. License: LGPL &larr; DEADLINK
*[http://mozile.mozdev.org/ Mozile] -- New-generation in-browser editor for Mozilla
*[http://php-html.sourceforge.net/ HTML Parser for PHP] -- a good candidate for inclusion in MediaWiki for parsing WYSIWYG editor output back to Wiki markup
*[http://diberri.dyndns.org/html2wiki.html HTML->MediaWiki converter] -- demo of the HTML::WikiConverter perl module
*[http://esw.w3.org/topic/HtmlDiff HtmlDiff solutions]
*[http://wikiwriter.sf.net Diderot - Demo for integrated Wikipedia editor - Win only]
*[http://wackowiki.com/WackoWiki WackoWiki] [ru] -- Wiki engine with built-in WYSIWYG editor
*[http://kupu.oscom.org/ OSCOM Kupu] -- Open Source Content Management: Kupu WYSIWYG XHTML Editor, easy to integrate and extend, uses CSS, BSD source code license
*[http://koivi.com/WYSIWYG-Editor/ KOIVI TTW HTML Editor] - cross browser, cross platform - '''some Safari/412 support!'''
*[http://moinmoin.wikiwikiweb.de/WikiSandBox?action=edit&editor=gui MoinMoin] (written in Python) used FCKedit as GUI wiki editor.
*[http://wikiwig.sourceforge.net/ WIKIWIG] --A lite WYSIWYG Wiki based on HtmlArea3. GPL, developed in PHP, so lite and easy to set up.
* [http://dojotoolkit.org/docs/rich_text.html Dojo Rich Text Editor] The Dojo rich text editor supports inline editing as well as WYSIWYG
* [http://www.linspire.com/ajaxwrite.php AjaxWrite] XUL based WYSIWIG editor, supports several file formats (RDF, PDF, MS-Word, etc); perhaps could be made to support WikiText
* The [http://www.uwa.edu.au/students/__squizlib/htmlarea/htmlarea-prod/examples/spell-checker.html HtmlArea 3.0 spell checker plugin]:
http://wp.aulinx.de/pics/htmlarea3_spellchecker.png
* WYMeditor: [http://www.wymeditor.org/ WYMeditor] is an open source web-based WYSIWYM editor.
*[http://twiki.org/ TWiki] an Enterprise Collaboration Platform written in Perl.
*[http://meta.wikimedia.org/wiki/Word_macros Microsoft Word Macros] which help converting MS Word to Wiki markup.

[[Category:MediaWiki Development]]
[[Category:MediaWiki tools]]
[[Category:MediaWiki extensions]]

Latest revision as of 00:56, 2 August 2010