[pmwiki-users] Question about the pmwiki editor and possibilities (advanced)

[Patrick R. Michaud]

On Tue, Mar 28, 2006 at 07:52:29PM -0800, Michael P Nagy wrote:
> The other day however, I was looking at the schools otherwise awful web
> page creation software for kids, which is entirely web based. It seem to
> use only javascript, and html and is processed on the server (another
> separate education department server) by php. Yet it enables the kids to
> see the changes. Its has a GUI sort of similar to PmWiki, with all the
> icons, yet when they change the text to bold, or change the text
> size/font, it updates in the web browser in real time seamlessly.
> 
> I am familiar with html and can code PHP, but I have never bothered to
> learn JavaScript. Can anybody tell me how it is possible to do this? Or
> point me to more information. I'm really interested in this as an
> option, because this is the only advantage the other option has over
> pmwiki for helping the kids put content on web pages. I've never come
> across articles about doing this. All software I have seen where the
> user enters input via the web page, well they always use symbols. For
> example all guestbooks I have seen insert smiley's as symbols before
> displaying them later with the smiley graphics.

The short answer to your question is that WYSIWYG editing greatly 
reduces the types of customizations that can be performed, and
restricts the browsers that can perform editing.

For example, the other package that you've seen that allows things
such as bold or text-sizing to take place directly in the browser
window is ->inherently limited<- to handling only those markups
that it has been pre-programmed to perform, and then it performs
its changes directly to the HTML code, and not the markup that
was used to produce the HTML.  In other words, the other package
uses HTML as its underlying storage format.

Unfortunately, this means that people with browsers that cannot
handle the Javascript can only edit the pages by viewing and 
editing the HTML directly.  It also means that it's not possible
(or at least fairly 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 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. :-)

> PS I am wondering if this is what the RichEdit add-on does? However the
> site says the following: "A lot of users (see pmwiki-users maillist)
> experience great difficulties after installing this RichEdit recipe.
> They all complain of loosing all contents after using the RichEdit
> script. None of these questions seems to be answered :-("

The RichEdit cookbook recipe was one person's attempt to integrate
an HTML-based Javascript editor within the browser and then 
convert the HTML back to wiki markup when saving.  I don't know
how well it worked, as I could never get it to run on my system,
and over time RichEdit appears to have been largely abandoned 
by the original author.  I'm thinking we should probably remove 
RichEdit from the Cookbook, or otherwise clearly mark it as an 
abandoned recipe, since all it seems to be doing at the moment is 
cause people to spend a lot of time hoping to get it to work and 
being very disappointed at the outcome.

Pm