Now that there is a free, commented, ready-made html-form element for Wysiwyg editing (limited to MS Internet Explorer 5.5 or higher, apparently
), there is also a challenge for Wiki programmers to use this component for a decent WysiwygWiki
Download page: http://www.interactivetools.com/products/htmlarea/index.html#demo
Please leave here your link(s) with timestamps to working public WysiwygWiki
(s), based on this component:
This is a Bidirectional Link to http://openwiki.com/ow.asp?OpenWiki%2FSuggestions%2FEditWYSIWYG
, where the good news came from. -- FridemarPache
Why this contest:
In a world of a myriad of Wikis with a myriad of ("simplifying") input format conventions on textareas, it is a great simplification to have now a uniform intuitive inputform. Besides that it may really save keystrokes and waiting time between text edit mode and html presentation mode. See DontModeMe
. -- fp
You won't exclude textbased Browsers, will you?
You could optionally or conditionally add a textarea. The condition could be saved as a preference cookie. -- fp
I downloaded the 26K file. I could edit the example locally and clicked in edit mode on a link, but it didnt jump
- the brutal variant: use a keyboard macro / a bookmarklet to save the modified form (if the modified flag is set) and jump to the new form.
- the wiki way: problem still open Dec 15, 2002, 15:12 PST
- ask BillGates
) shows 4,690 results as of 15/Dec/2002/4:10GMT. -- AndrewMartin
(who's also interested in this competition)
looks promising. You can download a free personal edition, that gives you the taste for the announced groupware. -- fp
One problem is that the wiki has to supply HTML content to the HtmlArea?
, and gets back HTML content when the page is submitted. This can be a problem if one is storing plain text (in my case eText), instead of HTML. Of course, one could use XML as a storage medium? Is there an XmlWiki?
did initial htmlarea3 support for PhpWiki
after doing the guiki port to phpnuke.
The problem is indeed the HTML parsing back to wiki formatted text. Once edited with HTMLAREA you can only save and edit it in HTML. Current PhpWiki
doesn't ship with htmlarea3 support, because of the possible viral effect and the lack of a parser. Into which format the parser converts the HTML code is not really important (=> WikiExchangeLanguage
), unless it can be easily converted to the proprietary WikiFormat
for the WikiEngine
in question. -- ReiniUrban
Of course, in order to ensure InterWiki
operation of the myriads of wikis out there, you need to standardize the interchange language. This though, does not mean you actually need to store
XML; you just need to be able to produce it (or whatever else this interchange might require). Another thought is to actually have an editor like lyx produce this interchange data. This then may be posted to the corresponding wiki, where it gets stored any way the wiki wants it. The point being that you have a real
editor for your serious WikiWork?
. Emacs has a wiki mode which is not really WYSIWYG, but it is close enough. But
the wiki-mode produces output for one specific wiki syntax. This renders it basically useless. Is there a WikiExchangeLanguage
? If not, maybe the time has come for there to be one. -- DimiterKurtev
uses the HTML editing capabilities of Internet Explorer and converts the HTML produced to nice XML for storage. Any browser-specific HTML idioms are normalized to a common format allowing WYSIWYG editing of the same content from different browsers.
Alain 2004-08-18: Is this contest still on? If so, I have a candidate WYSIWYG wiki editor crafted with Metacard. The latter is a WYSIWYG authoring tool (IDE). With my editor, you do all of the layout, click on a button, and voila ... the output is DHTML (layers, CSS, etc.). I'm now adapting it to also generate wiki markup, and adapting PmWiki
to support DHTML, as well as an API that will allow us (authenticated users) to update the wiki remotely (automation).