Also known as Wysi Wiki.
Approaches: The design of a WYSIWYG Editor for wiki seems very doable. Here are a couple of approaches:
for HTML versioning its possible to use
[Html Tidy | http://pecl.php.net/package/tidy] and then continue on per line basis.
HtmlDiff? functionality is available in perl and python - http://esw.w3.org/topic/HtmlDiff. Example http://wiki.webwareforpython.org/htmlwikisandbox (needs registering without approval). [proposal from wikipedia | http://meta.wikipedia.org/wiki/WYSIWYG_editor#HTML_to_Wiki_markup]
Why harmful at all? Surely this is the Wiki ideal.
Actually, it isn't. WikiWiki is supposed to be fast, which means fast to display, fast to read, and fast to edit and update. WYSIWYG editors are none of these. It takes time to load the code behind the editor. It takes noticably longer to display and layout the text you're editing. Hidden markup gets out of sync with what's on the screen all the damn time (JotWiki? anyone?). It takes forever to edit, because you're constantly switching between the mouse and keyboard. And finally, they don't use any standard text-area fields, which prevents the use of custom editors (e.g., Vim, via the mozex extension), thus making the user experience so unbearable that it derails your train of thought when typing. None of these things are ideal. --SamuelFalvo?
Having to use weird markup is the most uncomfortable bit about current Wikis. Accessibility isn't an issue because of keyboard shortcuts. Implementations that aren't cross-browser may be moderately harmful, but that's nothing to do with the idea of WysiwygWiki. I too would have liked to have seen the discussion. -- DannyAyers
:-) N888-8-26 :-) Danny, believe it or not, the prevailing opinion among old-school wiki users was(is?) that learning to use a wiki (a new concept for most everyone, to think about being able to edit a webpage at all) and its archaic text-code syntax was an "intelligence test of sorts" a very specific sort of intelligence that kept certain undesirables ("the video game generation") at bay :-) My opinion was(is) that the easier for new users you can make it, the more and wider-variety of contributors can participate and the better the results for everyone to share :-) I personally fought a wiki-battle on this point (when multiple editors jocky for space, both strongly believing their opinions, checking-up on the pages frequently, perhaps even removing or rearranging others comments to make their view more apparent to casual readers) and due to the widespread agreement on the promise of WYSIWYG wikis that I find here and now, I hope that I made a lasting contribution :-) My next project is an assembly language wikiserverOS for the ARM9 CPU in my Nokia 6600 smartphone that does nothing more than fixed-width font (basic character by character WYSIWYG!) so that it can edit its own code and evolve many different ways from there (recording, sharing and collaborating on music over short range 'whisper' wireless, for sure!) :-)
N888: There are those who disagree with you. You claim that letting all and sundry contribute creates "better ... results for everyone to share". The evidence of this wiki and many other fora is that there are many, many people who have nothing useful to say, nothing useful to contribute, but who will still insist on crapping all over the place. Sometimes they are just being a WikiPuppy, sometimes they are well-intentioned but misguided, and sometimes they are malevolent.
My direct personal experience is that requiring someone to invest some time and energy learning how to use a site means they are less likely to crap on it. Further, I'm willing to accept that some people may be turned away from this and I will lose the opportunity to learn from them. But then, if someone isn't willing to do some learning first, I think I'm going to be less likely to listen to them.
I look forward to properly implemented WYSIWYG wikis - it will be interesting to see if they are as hard to read, hard to follow, and visually assaulting as most private web sites. If they are, I doubt they'll get much high-quality traffic.
Oh, and please stop leaving your advertisements all over the place. I've removed some of them from the above - you are starting to smell of spam ...
You mean a PricklyHedge?
I remember that browser agnostic and not browser agnostic solutions were presented. Even a Java beans solution. A reference to AmayaBrowser, the W3C recommended free Wysiwyg Browser Editor with source, adaptable to a WysiwygWiki. Outlook Express as a Wysiwyg user interface. MicrosoftFrontPage. MicrosoftWord. Perhaps some people might wish to (re-)expand this. I see a great potential in this concept for an AllInOneWiki. For Java programmers, it might be a good idea to build on a Html browser kit: http://java.sun.com/products/jdk/1.3/docs/api/index.html. Look for: javax.swing.text.html, which provides the class HTMLEditorKit, supporting classes for creating HTML text editors, working online as applets or applications for joint editing. -- FridemarPache
Can someone please explain how the WYSIWYG part of WikiCpp works?
http://www 'dot' mywebos 'dot' com/Mywebos was one of the "dot com bubble" companies that popped. They obviously started with a huge BigDesignUpFront coding effort, based on VendorLockin? to MicroSoft, and when the VentureCapitalists ordered everyone to start turning a profit or eject they took the second option.
MyWebOs? promises they are working on a Netscape version of their server-side desktop metaphor, so we'll see what we can "borrow" for WikiCpp v. 2 when they do! "Browser agnostic", however, will be a long way away without a centralized fix like Java. -- PhlIp
Ok, then programmers with some minutes spare time might want to start a "Browser gnostic" Wysiwyg Wiki with Microsoft's DHTM edit control, usable from Script/VB/C++: http://msdn.microsoft.com/workshop/author/dhtml/edit/default.asp. Watch MsWiki for a realization with JScript. -- FridemarPache
http://www.SeedWiki.com is using ActiveEdit, a WYSIGWYG control as an optional page editor. Seems to work fine. We had to fiddle a little with the page parsing so that Wiki Names would still create pages. It works only for IE, but users seem to really like it.
That is the approach (I think) used by WebPageInPlaceEdits.
I have PhpWiki working on my server for posting up documentation. The only thing is that my wife hates the idea of using *, !, and # signs to start lines. She would prefer to push the button. For people like this, the WYSIWYG is the most accessible. BTW, my grandmother has no problem with wiki syntax. -- TD
I started a SourceForge project to help generate some demos of what is possible. I think when people actually see the editors, they will think "that's a lot easier that what we are doing now." Right now, I think people think the dB storage must include HTML. Not true, we can translate the other way too... Also, people who would like to keep with the current system of wiki text can keep intering [entering?] that way.
See http://www.wysiwiki.com/ ...