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
