version=pmwiki-2.2.10 ordered=1 urlencoded=1
agent=Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
author=simon
charset=ISO-8859-1
csum=Bespin
ctime=1153338126
host=202.37.32.2
name=PmWiki.WYSIWYG
rev=18
targets=PmWiki.PmWikiPhilosophy,Profiles.Pm,PITS.00421,Category.Wysiwyg,Category.Wikiwyg
text=(:Summary:Notes about WYSIWYG support in PmWiki:)%0a%0a'''Q: Does PmWiki support any sort of WYSIWYG editing?'''\\\%0a'''Q: Has anyone integrated the FCKEditor with PmWiki?'''%0a%0a''Pm's response:''%0a%0aThe short answer to these questions is that WYSIWYG editing greatly %0areduces the types of customizations that can be performed, and%0arestricts the browsers that can perform editing.  As such, it tends%0ato go strongly against [[PmWikiPhilosophy]] #5 ("Be easy to install,%0aconfigure, and maintain.").%0a%0aThe major problem is that browsers are limited in terms of the%0aamount of WYSIWYG editing that can be provided.  For example,%0amost in-browser editors such as FCKEditor are ''inherently limited''%0ato handling only those markups that they have been pre-programmed %0ato perform.  Furthmore, such editors perform their changes directly%0ato the HTML code, and not the markup that was used to produce the%0aHTML. In other words, in-browser WYSIWYG editors currently use%0aHTML as their underlying storage format.%0a%0aUnfortunately, this means that people with browsers that cannot%0ahandle the JavaScript would be able to edit the pages only by viewing%0aand editing the HTML directly.  It also means that it's not possible%0a(or at least prohibitively difficult) to support markups that don't%0ahave a direct analogue in HTML.%0a%0aOne approach that has been tried (with little success) is to%0aallow the browser to do direct WYSIWYG editing of the HTML, %0aand then attempt to convert the HTML back to wiki markup for %0astorage and editing by other non-capable browsers.  Unfortunately, %0athis can work only for a limited set of markups, and becomes%0aa nightmare if we want to allow wiki administrators to develop%0acustom markups.  (In other words, say goodbye to many cookbook%0arecipes.)%0a%0aIn theory one could write a rendering engine in Javascript%0athat would on-the-fly convert wiki markup into HTML for%0aWYSIWYG display during editing, but I don't know anyone who%0ahas seriously tried this.  Again, it can potentially work if %0athe complete set of available markups is known and fixed, but %0aonce the possibility of custom markup extensions is introduced%0ainto the system, the complexity becomes huge.%0a%0aSince local customization of markup is one of PmWiki's %0amajor strengths, that pretty much closes the door on WYSIWYG%0aediting until/unless we either decide to disallow custom markups,%0aor browser technologies improve to make it easier to have %0aextensible WYSIWYG editing in the browser.  %0a%0aAJAX shows some promise, but I think that WYSIWYG is still a bit%0abeyond its reach unless a site has a lot of bandwidth available%0ato handle rendering requests.  I'm very intrigued by what something%0alike Writely may be able to do, but I think it's limited in its%0acustomization potential.  (However, it's also not a good idea to %0aunderestimate Google's capabilities here).%0a%0aSince PmWiki's inception, I've basically taken the position that%0athe benefits of WYSIWYG editing, which could be considerable, %0aaren't worth the loss of flexibility and capability (such as custom%0amarkup and other items) that would be required to implement it.%0a%0aAnd I think that the fact that other web-editing frameworks%0acontinue to use symbolic markup over WYSIWYG editing is a%0agood indication of just how difficult the task really is.%0a%0aOTOH, if anyone wants to pay me a lot of money to tackle%0athe problem, I could see what I could come up with.  --[[~Pm]]%0a%0a%0a----%0a"Be easy to install,%0aconfigure, and maintain." %0ahtml is easy , wiki syntax isn't%0a%0aWhile it's a prevailing attitude of some, it's really not true.%0aHTML is a huge language space, with tons of inconsistencies%0adeveloped over time by many people who meant well, but were%0amore interested in their own goals instead of establishing%0asomething "sane".%0a%0a----%0aSee also [[http://pmichaud.com/pipermail/pmwiki-users/2003-August/001084.html | Pm's thoughts about markup selection]]%0a%0a----%0a%0aI would be curious to know if Adobe Spry (javascript and css) functions would work toward something like this.%0a----%0a* See ''and vote for'' [[PITS.00421]]%0a* See [[Category.Wysiwyg]] and [[Category.Wikiwyg]]%0a* For example see%0a** http://wikiwig.sourceforge.net/%0a** http://kupu.oscom.org/%0a** http://seedwiki.com/%0a** http://editme.com/%0a** http://timtam.codehaus.org/%0a** [[http://wiki.wordpress.org/WYSIWYG Plugin]]%0a** [[http://wiki.zoho.com/]]%0a** http://www.wikiwyg.net/%0a** [[http://geniisoft.com/showcase.nsf/WebEditors |Big list of WYSIWYG rich text web editors]]%0a** https://bespin.mozilla.com/%0a
time=1263945380