[Pmwiki-users] Re: DevQ: Intercept action=edit / preview / post
Sun May 2 10:05:32 CDT 2004
Patrick R. Michaud wrote:
> 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.
This is going to be good. Whenever Patrick 'thinks' about something,
you know it's going to be well formulated :)
> 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.
I'm working with http://www.kevinroth.com/rte/demo.htm which uses a
stylesheet that's in use on the site too.
> 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 agree that any WYSIWYG component mustn't mess about with existing
content, but if you create a group, & customize that group to use the
WYSIWYG add-in, then all content is in (X)HTML
> 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.
Sharing a stylesheet between the rendering & authoring component means
what you see in the browser/editor is what you get in the
browser/renderer. Mind you, as you point out in the next paragraph, it
could well look very different in another browser.
> 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.
I think that though this *is* true, we are moving towards more
consistent standards both in terms of output (text) and display. As
there are recognized difficulties at the minute, it doesn't stop us
dreaming/brain-storming over the direction we are going.
> 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.
No offense taken :-)
> 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 .
Again, nothing in there to argue about, but...
> 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,
See my previoius comment about a new group, implying that this is an all
or nothing implementation. But if WYSIWYG tools are available, why use
standard wiki markup? (Note:This ignores the fact that no way will a
_current_ WYSIWYG component do all standard wiki markup can).
Wiki's are hitting the mainstream, see
I first read about wiki in a Linux magazine, and have been invigorated
by the whole concept. It's now at the stage that WP were at 12 years
ago. Remember WordPerfect 5.1 - World leader with all its inline block
markup? When Windows came out, they didn't move quickly enough to the
WYSIWYG thing until way too late. Word 2.0 was hopless at large
documents, & nowhere near a quick, but it took over the World.
I really do feel that a WYSIWYGWIKI is only a matter of time, and why
shouldn't pmWiki be leading the way?
My tuppence worth :-)
More information about the pmwiki-users