This htmlarea is verry cool, got it to work in Mozilla and my twiki site within the hour!!! Verry cool. Usefull forum and a project at SF!

Demo: http://testwiki.mrjc.com/twiki/bin/view/HtmlAreaTest/WebHome

Please see the edit.tmpl attachement for how I use this htmlarea here. You will have to copy all the files that come in (beta v3.0) to the dir your/twiki/pub/htmlarea. After that in htmlarea.js you will have to change the line:
this.editorURL = ""
into:
this.editorURL = "your/twiki/pub/htmlarea"
And you will have to change all the hard-links in the edit.tmpl to point to this "your/twiki/pub/htmlarea". Hope to hear some results. I'd love to make this relative, so it will be easy to move to another twiki instance. Anyone?

-- GerkeKok - 22 Apr 2003

Comments:

• it should be named edit.htmlarea.tmpl to follow the TWikiSkins convention
• in edit.htmlarea.tmpl if you replace the /lb/pub/ hard links with %PUBURLPATH% no editing will be necessary.
  • with the possible exception of changing htmlarea-lang-nl.js to the local language (e.g. htmlarea-lang-en.js for english)
• In anticipation of this turning into a real plugin, the place to put the contents of htmlarea.zip is probably %PUBURLPATH%/Plugins/HtmlArea

• edit.htmlarea.tmpl: modified with the changes described above

I would not recommend anybody use this on a production wiki though. The code it puts out is html and unless everybody who uses your site uses this editor people will be effectively locked out of refactoring pages, which is one of the main reasons for using a wiki in the first place. Of course if somebody extends htmlarea so that it puts out TextFormattingRules instead of html [hint, hint] that changes everything. (^_^)

htmlarea could also benefit from optimization. It has a tendency to spew tags all over the place:

<br /><font size="6"><br style="font-family: times new roman,times,serif;" /></font>
<address><font size="6"><span style="font-family: times new roman,times,serif;">
this phrase is in times new roman</span></font></address>

-- MattWilkie - 22 Apr 2003

   $ cd twikibasedir
   $ cd patches
   $ wget 'http://www.interactivetools.com/iforum/Open_Source_C3/htmlArea_v3.0_-_Alpha_Release_F14/htmlArea_3%3A_Alpha_release_P7101/gforum.cgi?do=post_attachment;postatt_id=263;guest=928950&t=search_engine'
   $ mv forum.cgi\?do\=post_attachment\;postatt_id\=263\;guest\=928950\&t\=search_engine htmlarea.zip
   $ mkdir -p pub/TWiki/HtmlAreaPlugin
   $ cd pub/TWiki/HtmlAreaPlugin
   $ unzip ../../../patches/htmlarea.zip

then:

   $ cd twikibasedir
   $ cd patches/
   $ wget http://twiki.org/p/pub/Codev/HtmlAreaEditor/edit.htmlarea.tmpl
   $ mv edit.htmlarea.tmpl ../templates/

then:

   $ cd twikibasedir
   $ cd patches/
   $ wget http://twiki.org/p/pub/Codev/HtmlAreaEditor/HtmlAreaPlugin.htmlarea.patch
   $ cd ..
   $ patch < patches/HtmlAreaPlugin.htmlarea.patch

NB. Use of the Plugins web is not endorsed yet, so I've posted another version that makes this sit in the TWiki web.

To invoke it:

• Go to the edit URL for a page
• Once loaded, append the parameter skin=htmlarea to the URL line.
• The links below don't work because htmlarea is not installed here, but they work on your machine if you install HtmlAreaEditor:
  • e.g. http://twiki.org/cgi-bin/edit/Codev/HtmlAreaEditor?t=1053672764&skin=htmlarea or
  • e.g. http://twiki.org/cgi-bin/edit/Codev/HtmlAreaEditor?skin=htmlarea

I guess this is very almost the HtmlAreaEditorPlugin.

Issues:

1. The JavascriptEditor has some additional widgets that are useful, e.g. The Topic list popup. It would be good to pull these in, and have the merge point in the template so that the htmlarea.zip file can remain unmodified.

Re: conversion back to WikiML:

I feel the refactoring question mentioned above is a bit irrelevant as long as the HtmlAreaEditor is always loaded if the page is a html editor based one. This means we need PageType

-- MartinCleaver - 23 May 2003

Okay, perhaps I got too enthusiastic about the HtmlAreaEditor, but it now works!

There is now a patch and instructions (above) to make the editor work properly.

It would be good to use a metadata item designate the PageType; this would be used to associate the HtmlAreaEditor with .html files, word with .doc files etc. Please take a look.

-- MartinCleaver - 23, 26 May 2003

Jeeez! You can even paste from Word into Html area and it retains all the formatting!!! Follow the instructions above to try it on your TWiki site.

This seriously changes the value of TWiki. If I didn't have homework for my course that I must complete I would package all of the above into the plugin page at HtmlAreaEditorPlugin

-- MartinCleaver - 28 May 2003

Does that include things like:

• headings? If yes, do they appear then with TWiki markup (---++), HTML <H2>..., or something else?
• (bulleted and numbered) lists? Again, do they appear with TWiki markup, HTML, or something else?
• tables?

-- RandyKramer - 28 May 2003

They are all done in HTML, but given TWiki claims to support HTML content this should not be a problem. From a user perspective it is all transparent - everything is WYSIWYG.

To answer your questions:

• Headings: yes
• Lists: yes, both
• Tables: yes - even editing

This is possibly the most important thing I have seen about TWiki for two years.

-- MartinCleaver - 28 May 2003

WikiML Refactoring only becomes irrelevant if you are willing to restict your user base to specific browsers (IE5.5+ and Mozilla 1.3+). Another aspect which is not as wide reaching but still worth evaluating is that the weight (in kb) of all htmlarea-edited pages will increase (at least) threefold.

Don't get me wrong, I don't want to be a wet blanket. I think something very like this is exactly what is needed by many wiki users, myself included. I'm just not willing to so easily disregard what is, for me, an essential aspect of wikidom.

I hope that htmlarea will evolve into something that produces lightweight html (which it most emphatically does not at this point) by default, with optional "dialects" (e.g. xhtml, xml, wiki-ml, twiki-ml, etc.)

-- MattWilkie - 28 May 2003

Pros and cons

(please add to this)

• Pro:
  • low threshold, no learning curve
  • easier, no more counting spaces with bulleted lists
  • potential integration with other office documents

• Con:
  • once started with the editor you are stuck with it. In editing mode you will need the editor to make the older comments readable.
  • it does lock users out. On my Mac I can't use it. But instead of Javascript you could use a Flash based editor, like this Rich Text Editor.
  • bigger files
  • ugly html under the hood

• Questions:
  • IS it any easier to use, or does it only appear that way? This is something that should be tested. What users say might be different than what they do or experience. See this recommend read: Testing the Three-Click Rule.
  • is integration with existing office documents a valid pro? How does this work out in practice?
  • What about anchor linking topics?
  • What about text formatting like verbatim and nop?. Does it integrate?
  • How to incorporate power user functionality like advanced formatting (TOC)?

Those who have installed the editor in their TWiki need to give feedback on this.

-- ArthurClemens - 01 Jun 2003

I liked the htmlarea javascript control - and especially the fact that it supports both Mozilla 1.3a+ and IE. This way one can provide a consistent experience across the team. However htmlarea stores HTML back in the pages, so differencing and revisions becomes that much more complicated.

I was looking for a way to allow WYSIWYG style editing but at the storage time convert the HTML back to Wiki format. I found a few examples of html2twiki and html2wiki - however i figured it's better to just do it in the browser before the submit.

I developed a html2wiki.js script, that essentially generates TWiki syntax for the given DOM. I currently support Bold, Underline, H1, H2, H3, UL (OL's are currently treated as ULs) as well as general purpose FONT and SPAN tags that are replicated as-is in the output. I ignore other tags to prevent cluttering of the output. For instance, if you were to cut and paste from an open Word document - you'll realize that the generated HTML is a mess.

I had to modify the edit script such that it would render the TWiki page in HTML if the htmlarea skin was being used. With this in place, both non-htmlarea and htmlarea users can collaborate on the same pages without clobbering each other.

Also - I use KoalaSkin on my pages, however wanted certain users that wanted WYSIWYG editing to be able to enable just an htmlarea style widget within the KoalaSkin pages. I did this by defining a new EDITSKIN preference within the users page, and a new edit.htmlarea.tmpl.

Anyways - this is work in progress - and the first version of the html2wiki.js is attached for others to leverage. If someone is interested I can show how I modifed htmlarea to support this.

-- AshishKumar - 03 Jul 2003

That's great Ashish, is there a demo you can put up somewhere? I really think that many didn't try the HtmlAreaEditor instructions I put up here because it took some effort to install them.

-- MartinCleaver - 03 Jul 2003

This is really great progress! Ashish' additions can take away all the negative points I listed above - except for cross platform issues probably, but it is good that the 2 edit ways can co-exist.

-- ArthurClemens - 03 Jul 2003

>If someone is interested I can show how I modifed htmlarea to support this.

yes please!

-- MattWilkie - 07 Aug 2003

I got this e-mail reply from Ashish:

Unfortunately the initial version of the html2wiki.js I had written needs a lot more work in figuring out when to chomp a space and when not to. While it works to some extent, I wasn’t able to roll it out in our twiki usage. However, someone who’s an expert on Javascript might be able to do a better job with that.

So who can assist? Or knows who can?

-- ArthurClemens - 22 Aug 2003

As we created a wiki open to the general public to discuss the future : http://www.2010virtual.com/twiki/bin/view/Main/WebHome we are interested and tested also textarea. We found that quite often, it did not work, replacing a space before a WikiName by the code & n b s p ; thus forbiding the creation of new pages.

Has someone experienced such problems also or found solutions?

-- MaloGirodDeLAin - 05 Sep 2003

Okay - I've knocked up a demo that you can try: http://testwiki.mrjc.com/twiki/bin/view/HtmlAreaTest/WebHome

-- MartinCleaver - 26 Sep 03

NB. TikiWiki now has HtmlArea integrated with it. http://www.interactivetools.com/forum/gforum.cgi?post=13445;search_string=wiki;t=search_engine#13445

-- MartinCleaver - 26 Sep 03

Thanks Martin but when testing your demo it says: This demo is temporarily down. Could you reinstall it? I would prefer to continue with TWiki. Thanks.

-- MaloGirodDeLAin - 01 Oct 2003

Sorry about that. The demo now functions agains.

-- MartinCleaver - 13 Oct 2003

Just for the record, I could not get the demo to work on my Mac, either with Safari or IE 5.2. In Safari, it gave a nice message about not being compatible with my browser but would try. All the buttons showed up but nothing worked. I could not even manually edit the text box which was empty. In IE 5.2, all the buttons showed up but there was no text box at all. Oh well, it looked cool!

-- LynnwoodBrown - 14 Oct 200

Hmm, yes, http://www.bris.ac.uk/is/projects/cms/ttw/ttw.html does say that it won't work on a Mac. It does mention the editor in campfire, so maybe the extraction / incorporation of that can be a project for someone with an interest and the right gear.

If anyone wants to develop a Mac solution I can offer a login on my testwiki to facilitate.

-- MartinCleaver - 14 Oct 2003

One more comment on Mac compatability: it would be great if HtmlAreaEdit could be invoked conditionally based on what browser and client OS was being used. At least this way, Mac users would still be able to edit the topic. As it is, HtmlAreaEdit essentially locks out Mac users altogether.

-- LynnwoodBrown - 14 Oct 2003

In-Browser Editing with publishing to CMS (Content Management System) for Mozilla at O'Reilly -- PeterMasiar - 17 Oct 2003

Martin wrote: "Sorry about that. The demo now functions agains".

Yes, thanks but it shows the same problem I indicated above: ...replacing a space before a WikiName by the code & n b s p ; thus forbiding the creation of new pages. In the example I reproduced on your demo, it included a < p >.

-- MaloGirodDeLAin - 25 Oct

Malo - thanks for the feedback, my apologies for not reading what you wrote!!!

I have fixed (fudged, actually) a workaround on my server.

The problem is created by TWiki's rule that WikiWords have to be prefixed by a whitespace. Peter T regards this a feature - it is the same reason as causes BoldTWikiWordsAreNotHyperlinked. Peter - would you be willing to allow > as a leading character?

On my server I created a plugin (HtmlEditorFudgePlugin) that intercepts (see http://testwiki.mrjc.com/twiki/bin/view/TWiki/WebHome) the BeforeSaveHandler.

sub beforeSaveHandler
{
    my $text = $_[0];
    my $topic = $_[1];
    my $web = $_[2];

    writeDebug( "- ${pluginName}::beforeSaveHandler( $_[2].$_[1])");

    writeDebug("before: $text");
    $text =~ s/<p>/<p> /g;

    writeDebug("after: $text");
    $_[0] = $text;
}

It works by inserting a space before the WikiWord.

The regex should be modified to only insert a space before the WikiWord if there is not one already there.

Hopefully the CoreTeam will change TWiki to permit a leading > tag.

In the meantime, if you see anything else wrong with it, please let me know.

-- MartinCleaver - 27 Oct 2003

Yes, it seems to work. It adds spaces before each part of a WikiName making it a Wiki Name but why not, other wikis like a php wiki I know are doing the same thing. It seems also to solve the problem when a ; is before a WikiName or a >. I also hope this could be integrated

-- MaloGirodDeLAin - 06 Nov 2003

I've changed this to a feature request as we need cooperation from the core team and it is apparent that they have not noticed my request above (because they have certainly not said anything).

Incidently, friends, you have to edit the page to see the editor in action. Make what changes you like, I don't mind!!

-- MartinCleaver - 09 Nov 2003

If I undestand correctly the above includes a request to change the definition of a WikiWord. If this is required then I suggest this is put in as a specific feature request in its own right.

• Yes, I mean currently >WikiWord does not link yet but it needs to. -- MartinCleaver - 09 Nov 2003
• Yes, you are right, minimally this should be the feature request AllowWikiWordsToBeProceededByGT

I am confused reading the above if it is < or > that is required. The text says <, but the example code looks to be for >

• You are quite right, I meant >. The change is to allow a > immediately before a WikiWord. - I've changed the above text to match the code. -- MartinCleaver - 09 Nov 2003

-- JohnTalintyre - 09 Nov 2003

1. Thanks John, I've factored into your comment
2. We need to catalog potential problem areas, determine impact and plan solutions.

e.g.

Issue	Choices	Solution chosen
No way of choosing whether its an HTML page or a TML page	on page create
Do we need a way to convert	If different user types, probably not	Allow on create, then fix at this type and assume it'll be a technical user that will want and do any conversion manually
Page History will not work for HTML pages	Live without it; Find a HTML diff feature	live without it initially, measure impact. Evaulate http://search.cpan.org/dist/HTML-Diff/
Instructions will need to be changed	Overhall instructions; just add a comment to the top	Nieve users don't want to read instructions anyway
Core does not need TML rendering	Live with it; move to a plugin	Live with it in the interim
Needs more testing	Distribute as a plugin; allow people to test at http://testwiki.mrjc.com	Wait for AllowWikiWordsToBeProceededByGT to be implemented, then package
Excludes Mac editing completely Not true. Safari doesn't work, but Mozilla does. See below	Test for client OS and load regular text box for Macs or recommend user to use Mozilla

Please add more issues

-- MartinCleaver - 09 Nov 2003

Ok, we have now established that AllowWikiWordsToBeProceededByGT will not fly. Current thinking is that we will need to post process the topic when it leaves the HtmlTopicEditor to insert a space and preprocess to remove it again. I'm thinking that we should record where these get inserted, because we are bound to want to delete them again.

Would it harm to add '<added-space> ' beforehand? I'm just concerned in case repeated edits cause extra spaces.

-- MartinCleaver - 09 Nov 2003

I'm confused by the common references to HtmlAreaEditor not working on Mac. Just because the (system default) Safari browser doesn't work doesn't mean Mac users can't use it. Safari's handling of text areas without an undo function makes it less usable anyway for changing any larger amount of text (without hitting save all the time). Not to mention other Safari glitches like frequent cursor submarining of the insertion caret.

Here's a quick test suite to show which browsers work with the editor and not:

As a Mac user I think this development is significant enough to go ahead with Mozilla support only. Just consider Mozilla the "TWiki editor client" for Mac. Perhaps it's even possible to fire up Mozilla (if installed) when you click the Edit-button?

(text in status table above about negative status of Mac updated to refer to this comment)

-- StefanLindmark - 10 Nov 2003

I tested it finaly, and it is awesome. But... I really miss page history. Even if I just added without refactoring, rdif shows all previous page contens as deleted and added anew. This seriously screws change tracking, IMHO major selling point of twiki. Any idea why it is so and if it's possible to fix it? Other than that, I love it.

-- PeterMasiar - 10 Nov 2003

I have the same problem too with the page history. Really frustrating. Is there a solution out there? I don't understand why the page history/versioning doesn't work since TWiki is able to interpret and understand html? Maybe its just me, can anyone help me to understand why? If this page history can be fixed, then htmlarea really is a god send! Especially for people who have difficulties with the TWiki notation! Any help would be appreciated! You can contact me on steven@dwlPLEASENOSPAM.co.uk.

-- StevenCheung - 12 Feb 2004

Updated Mac Safari browser compatibility.

-- LynnwoodBrown - 12 Feb 2004

Just wanted to draw attention here to another possible approach for integrating HtmlAreaEditor into TWiki proposed by ManishKaduskar in WordProcessor - and also his request for help with it.

-- LynnwoodBrown - 20 Jul 2004

Ok I've cracked it ! I'll put a detailed update (with the changes etc) about it asap, once I've consolidated what all did I change. Thanks Lynnwood for all the support.

-- ManishKaduskar - 22 Jul 2004

I've put up detailed instructions about Integrating HtmlAreaEditor into TWiki on WordProcessor. Please feel free to let me know of what all can I do to better the code. Since my school is starting next week, I would not be able to give much time on it for a few days though

See IntegrateHtmlAreaEditor

-- ManishKaduskar - 24 Jul 2004

This editor is distributed under BSD license from SourceForge project htmlArea, http://sourceforge.net/projects/itools-htmlarea/. One of the developer is Mihai Bazon, the creator of the JS Calendar, so it must be a good piece of software. If it only could be taught TWikiML!

-- PeterThoeny - 29 Sep 2004

The demo is not working anymore. It says the web does not exist. Has the problem with ">" preventing WikiWords from being recognized been fixed? If this won't be changed in the official release of TWiki, somebody ought to make a patch.

-- DavidBourget - 11 Feb 2005