[pmwiki-users] WYSIWYG on PmWiki

Dominique Faure dominique.faure at gmail.com
Tue Jun 18 01:04:39 PDT 2019

A wiki engine work is mainly a one-way rendering from the wiki text into
html during page building.

Dealing with a WYSIWYG editor would consists in handling the exact
opposite, ie. getting back some html from a browser's content-editable
block (the WYSIWYG equivalent of a textarea editing) and translate it into
wiki markup.

If this can be done more or less easily for basic styling, the task is
rather difficult for complex markup such as tables or div sections and
almost impossible for pagelist directives or form elements and all kind of
custom stuff defined by various cookbook recipes.

Therefore, I'm afraid that in this case, the "Worse" is the best.


On Tue, Jun 18, 2019 at 6:24 AM Svetlana Tkachenko <svetlana at members.fsf.org>

> Peter Kay <pkay42 at gmail.com> wrote:
> >
> > > It would be nice to know how Google Docs overcomes this problem
> >
> > Probably through the liberal application of money, which can hire people
> to work.
> >
> > Pmwiki's markup is translated to HTML server-side by a php-based engine.
> In order to have a WYSIWYG editor, you would need a way to translate
> client-side, probably javascript?
> Does it have to be javascript? Perhaps an api which can translate from
> html to markup and back on the server side?
> With another wiki the translation from html to markdown is enormously
> difficult. Is this the case here?
> They resolve this by adding additional attributes (like <p
> data-foo="bar">) to the html markup. Is this the best approach?
> -- Sveta
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20190618/e4a0387b/attachment.html>

More information about the pmwiki-users mailing list