SKULLZONE
PmWiki

WYSIWYG

Q: Does PmWiki support any sort of WYSIWYG editing?

Q: Has anyone integrated the FCKEditor with PmWiki?

17-May-2011: A fund drive? has been setup to cover the costs of creating a WYSIWYG capability for PmWiki.

July 2017: See/try the addon Worse?:

Pm's response:

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.

Unfortunately, this means that people with browsers that cannot handle the JavaScript would be able to edit the pages only by viewing and editing the HTML directly. It also means that it's not possible (or at least prohibitively difficult) to support markups that don't have a direct analogue in HTML.

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.)

In theory one could write a rendering engine in Javascript that would on-the-fly convert wiki markup into HTML for WYSIWYG display during editing, but I don't know anyone who has seriously tried this. Again, it can potentially work if the complete set of available markups is known and fixed, but once the possibility of custom markup extensions is introduced into the system, the complexity becomes huge.

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.

OTOH, if anyone wants to pay me a lot of money to tackle the problem, I could see what I could come up with. --Pm?

"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 recipes


This page may have a more recent version on pmwiki.org: PmWiki:WYSIWYG, and a talk page: PmWiki:WYSIWYG-Talk.