[Pmwiki-users] Re: DevQ: Intercept action=edit / preview / post

Patrick R. Michaud pmichaud
Sun May 2 08:21:24 CDT 2004


In the interest of assisting those who are looking at WYSIWYG wiki
features, I thought I would just pass along the thoughts and strategies
I've had over the past couple of years regarding this topic.

Having looked at HTMLArea and thought about it *a lot* over the past 
few months, I think that it will be very difficult to get reliable 
results with the approach of converting HTML into wiki markup.  Also, 
I don't know how a WYSIWYG editor will be able to properly handle 
CSS properties for the HTML.

My reading on the best approach to this problem is to design a WYSIWYG 
editor that understands basic wiki markup -- i.e., it can store the 
edited text internally as wiki markup and convert the most basic wiki markup 
sequences into HTML for local display.  With this approach one could perhaps
handle the basics of bold, italics, paragraphs, and lists (which is likely
sufficient for most people wanting to use WYSIWYG).  However, I think it's
highly unlikely that any WYSIWYG plugin is going to be able to support
the entire range of features available via wiki markup.

I've long held that (1) WYSIWYG is possible only when the editing software 
has complete control over the rendered output, (2) that this only happens
in very specialized or restrictive applications and contexts, and (3)
that collaborative web authoring is not one of these contexts given current
browser standards and trends.  In other words, until browsers are consistent
in the way text is rendered, the fact that authors use different browsers 
will cause lots of incompatibilities and annoyances.  And since it's a
basic principle of the web that a browser is given some latitude in how 
it chooses to render to a particular output device, these inconsistencies
are likely to always exist.

My comments above are *not* meant to discourage development of WYSIWYG
capabilities for PmWiki, but merely to point out some of the difficulties
and challenges to WYSIWYG that I believe to be inherent to the web itself.
Last summer I also wrote a fairly long article on this topic that may be
worth looking at, see http://pmichaud.com/pipermail/pmwiki-users_pmichaud.com/2003-August/001084.html .  

One last thought on implementation:  Because of PmWiki's ability to customize
the markup language, any WYSIWYG system has to be able to either understand 
such customizations or else preserve custom markup sequences across edits.
Authors are likely to be very annoyed if their page loses custom markup
sequences because someone edited the page with a WYSIWYG editor that
couldn't understand them.  Lacking this ability, I fear that WYSIWYG may
restrict the customizations that can be made to the markup language.

My $0.02,

Pm


On Sun, May 02, 2004 at 02:36:40PM +0100, David Jackson wrote:
> 
> >Comments, suggestions, help, all graciously accepted.  I'm a bit over my
> >head here in the programming dept., but I just couldn't resist.  I see
> >future Wiki's using a strictly wysiwyg interface, and dispensing
> >completely with the ancient wiki-markup that most Wikis currently use.
> >Until that time however, I'm trying this ideai.
> 
> I whole heartedly agree.  I had a go at this, using HTMLArea, but was 
> beaten by my lack of ability.  You can see how far I got at
> http://glossopian.co.uk/_wiki/pmwiki.php?pagename=Main.HomePage
> 
> This is documented at http://www.pmichaud.com/wiki/Cookbook/HTMLAreaWiki
> 
> I am now playing around with yet another script, 
> http://www.kevinroth.com/rte/demo.htm
> 
> Dave
> 
> -- 
> Pmwiki-users mailing list
> Pmwiki-users at pmichaud.com
> http://pmichaud.com/mailman/listinfo/pmwiki-users_pmichaud.com



More information about the pmwiki-users mailing list