Q: Does PmWiki support any sort of WYSIWYG editing?
Q: Has anyone integrated the FCKEditor with PmWiki?
The short answer to these questions is that WYSIWYG editing greatly reduces the types of customizations that can be performed, and restricts the browsers that can perform editing. As such, it tends to go strongly against PmWikiPhilosophy #5 ("Be easy to install, configure, and maintain.").
The major problem is that browsers are limited in terms of the amount of WYSIWYG editing that can be provided. For example, most in-browser editors such as FCKEditor are inherently limited to handling only those markups that they have been pre-programmed to perform. Furthermore, such editors perform their changes directly to the HTML code, and not the markup that was used to produce the HTML. In other words, in-browser WYSIWYG editors currently use HTML as their underlying storage format.
One approach that has been tried (with little success) is to allow the browser to do direct WYSIWYG editing of the HTML, and then attempt to convert the HTML back to wiki markup for storage and editing by other non-capable browsers. Unfortunately, this can work only for a limited set of markups, and becomes a nightmare if we want to allow wiki administrators to develop custom markups. (In other words, say goodbye to many cookbook recipes.)
Since local customization of markup is one of PmWiki's major strengths, that pretty much closes the door on WYSIWYG editing until/unless we either decide to disallow custom markups, or browser technologies improve to make it easier to have extensible WYSIWYG editing in the browser.
AJAX shows some promise, but I think that WYSIWYG is still a bit beyond its reach unless a site has a lot of bandwidth available to handle rendering requests. I'm very intrigued by what something like Writely may be able to do, but I think it's limited in its customization potential. (However, it's also not a good idea to underestimate Google's capabilities here).
Since PmWiki's inception, I've basically taken the position that the benefits of WYSIWYG editing, which could be considerable, aren't worth the loss of flexibility and capability (such as custom markup and other items) that would be required to implement it.
And I think that the fact that other web-editing frameworks continue to use symbolic markup over WYSIWYG editing is a good indication of just how difficult the task really is.
"Be easy to install, configure, and maintain." html is easy , wiki syntax isn't
While it's a prevailing attitude of some, it's really not true. HTML is a huge language space, with tons of inconsistencies developed over time by many people who meant well, but were more interested in their own goals instead of establishing something "sane".
See also Pm's thoughts about markup selection
- See and vote for PITS.00421?
- See Category.Wysiwyg? and Category.Wikiwyg?
- For example see
- DokuWiki WYSIWYG plugins
- SPAW Editor
- http://wiki.wordpress.org/WYSIWYG Plugin
- Big list of WYSIWYG rich text web editors
- 12 Free Online Rich Text Editors (RTE) another list
- ACE (formerly Bespin and Skywriter), editArea and CodeMirror have the potential to highlight wiki code
- Itty Editor seems to do WYSIWYG in HTML but then has automatic 2-way conversion to/from markdown
- What you see is for the win - an article claiming that the addition of a visual rich text editor in the MediaWiki software got eight times the participation.
- InlineEditor will allow editing of sentences, sections or templates in a Wikipedia page.
- Editing 2.0 - MediaWiki's upcoming visual editor and the future of templates PDF presentation from a MediaWiki developer. See also Wikia RTE