Summary: Talk page for WYSIWYG.
FidelioEspoir 26 april 2019 Just a few remarks. (you can rewrite this in good english ;-)) To make easy the editing for my reader there is another solution : modify the guieditbutton in the script guiedit.php. In my web site (http://www.toposcopie.fr) all the code for description is proposed with near 30/40 buttons like a palette for a painter. I have to modify the cookbook guiedit.php. Awful ! I know ... Perhaps it would be better to have a SiteAdmin.Page to write the new buttons ? But I'm not informatician. My solution is do-it-yourself ! ;-) Thanks for all !
>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. -Pm
While not disagreeing with the difficulty of the task, would like to point out that Wordpress includes WYSIWYG editor (which generally does not work for markup added by plugins, unless those plugins explicitly provide a hook for the WYSIWYG editor), and Wikipedia finally launched their WYSIWYG editor. The latter, I think, both shows the difficulty of the task (it took a loooooong time), but also the desirability of the editor.
- Wikimedia rolls out WYSIWYG visual editor for logged-in users accessing Wikipedia articles in English
- Inventing as we go: building a visual editor for MediaWiki
Michael Paulukonis January 14, 2014, at 08:16 AM
The problem with comparing PmWiki with "others" is that in the case of the "others" they don't use markup in pages, they use HTML. So in reality they have a WYSIWYG around HTML (though they translate a type of markup into HTML). PmWiki doesn't do this, but instead makes it very easy to extend the markup language and even change how it's interpreted since page content is not stored as HTML (like the "others"). It's a key difference.
So, you either greatly greatly restrict what you can do in PmWiki, or you learn to love how it works.