GHOP #86: Evaluate all 5.x WYSIWYG, WYSIWYM, rich-text etc. editors

A few notes based on my previous experience working with WYSIWYG editors:

Does it generate valid XHTML

While it would be nice if we could fix all of the editors, this is out of the scope for the module maintainer; the issue should be punted to the respective publisher of the WYSIWYG editor itself.

• One of the big sticking points of these editors is what they recommend as input formats. HTML is a very difficult format to do properly, and often the restricted filtered HTML format doesn't allow users to take full advantage of the editor's functionality.
• I personally like light-weight editors that have a snappy JavaScript loading time. But this doesn't really have anything to do with the module maintainer.
• Also, most of the modules in "filters and editors" are filters; only a handful (less than half a dozen, last I counted) are editors.

What would be neat if we had a generic editor hook interface so that integrating new editors required writing a minimal amount of glue code that included the necessary JavaScript files and modified the textareas accordingly. This is out of the issue scope, though.

Are tables allowed in posts? (doesn't seem like it here...)

Assigning to self.

subscribing

Task passed due date with no response from student, so I'm opening this back up.

Subscribing. And:

- Core devs are not convinced of having a wysiwyg editor in Drupal core. In the meantime, I'm not sure either.
- However, having a Wysiwyg API in Drupal core seems like a valuable addition for D7.
- This task could be enhanced to complete the already started comparison about Wysiwyg editor module settings, which would instantly push development of Wysiwyg API to the next level.

Well, I'm afraid the holidays were much busier than I had anticipated, and I didn't get very far on this task. I did install all the modules and run them through coder.module (only one of them actually passed), but I haven't been able to go through and try to use all of them and check for bugs or see which one I liked best.

I should be able to get it done this weekend, but I doubt I can do it any sooner. If that's not soon enough, feel free to reopen the task. I"ll just have to try and claim it again a bit later. :)

Dan

coder.module test

• BUEditor: Fails
• FCKEditor: Fails
• HTMLArea: Fails
• nicEdit: Passes
• TinyMCE: Fails
• Whizzywig: Fails
• widgEditor: Fails
• WYMEditor: Fails
• XStandard: Fails
• YUI Editor: Fails

You can get the logs of all the errors in coder.txt.

Dependencies

• BUEditor: None
• FCKEditor: None
• HTMLArea: None
• nicEdit: None
• TinyMCE: None
• Whizzywig: None
• widgEditor: None
• WYMEditor: None
• XStandard: None
• YUI Editor: YUI

HTML Validation

• BUEditor: Valid
• FCKEditor: Valid
• HTMLArea: Untested
• nicEdit: Failed
• TinyMCE: Failed
• Whizzywig: Valid
• widgEditor: Valid
• WYMEditor: Valid
• XStandard: Valid
• YUI Editor: Failed

Overall Impressions

• BUEditor: This isn't really a WYSIWYG editor. It provides buttons which will automatically insert the HTML into Drupal's default plain text box. Although this does make it easier to create the posts, it is not quite as user friendly as a true WYSIWYG editor. To offset this however, it gives you a quick-preview button. This is a far faster way to preview text than Drupal's preview, and is an acceptable workaround for the lack of seeing what you get as you edit it.
• FCKEditor: This wasn't the most friendly to use. When installing it like usual, it did not automatically fill in the plain text boxes with the editor. Going into the admin page, I discovered that I had to download and install FCKEditor separately, then it could be used. (Of course, all this was detailed in the readme, but very few people actually read those) Once it was installed, it worked flawlessly - by far one of my favorite editors available.
• HTMLArea: Unfortunately, this editor also required going to a 3rd party site to download the editor. Once I had installed it, the was no visible way to make it work. I went through their readme and install.txt, but neither of them seemed to work. I would definitely not recommend this editor to anyone.
• nicEdit: As the only editor which passed the coder.module test, I had high hopes for this editor. Initially they were filled. This editor did not require going to a 3rd party site to download the editor. As soon as the module was enabled, all the plain text boxes were replaced with the WYSIWYG interface. My biggest problem with this was that, unlike FCKEditor, there were no keyboard shortcuts available within the editor.
• TinyMCE: Like most of the others, TinyMCE required going to their site to get the editor. After doing this, I had to setup a profile to allow myself to use the editor. Going with all the defaults produces an error until you give roles the 'access tinymce' permission. Although other editors had required that users have a certain permission, they had all given me, the admin, permission by default. Even after giving myself permission, it took awhile to notice that TinyMCE (by default at least) doesn't automatically replace the text boxes. It puts a small link underneath it allowing you to enable it. There may be a setting to change this, but by default I would find it much easier to simply replace the text box as expected.
• Whizzywig: I'll never understand why all these modules don't just include a version of the editor. After installing both this and the extension to allow for XHTML, I tried to create a story with the editor. This editor has a slightly different interface than the rest. While most editors use some relatively standard icons to indicate what the buttons will do, Whizzywig uses only text. I have no problem with text, but this makes it so that the toolbars take up more room in the editor. Additionally, there is no way to tell when the different text styles (bold, italic, etc) are activated. There was really only one other problem I had with the editor. Once I created a link, it was nearly impossible to tell it that I only wanted the link to be on one word, not the whole paragraph.
• widgEditor: Once the module was installed, there was no need to go to a 3rd party site for the editor. However, I had little hope for the module when I saw it's admin summary. It was left as the default example message for when people make their own module. Going into the settings, I noticed it was definitely easy to configure; the only option was to make it the default editor. I did this, and went to create a new story. In sticking with their obvious 'less is more' strategy, the editor provided for only the most basic of editing. Overall however, I enjoyed the experience with this editor. As long as you are not planning on using the editor for anything complicated at all, I would highly recommend this editor.
• WYMEditor: I think people are finally getting the installation right. Yet again, this module did not make me go to their site to get the latest version of the editor. Once I created a new profile for the editor using all the default settings, I headed off to create another story. The editor was beautiful to look at. There was a toolbar on top for the basic text formatting, and the different headings were all in a sidebar. Then I tried to use it. It would not learn that I didn't want to close my tags at the end of every paragraph. It was nearly unusable, which for me at least, was a disappointment. It looked so promising.
• XStandard: Ouch. This editor goes back to the evils of 3rd party sites. To make this pain even worse, it gives you no hint that you need to do so in the administration page. The only time you realize this is when trying to make a story. Even in their message, it doesn't give you a link to the website. (to be fair, all this is detailed in the readme, but as I said with FCKEditor, very few people actually bother to read them) Just in case all this wasn't hurting you enough, their download site requires you to give them your email address. For all this trouble, it had better be one heck of an editor. Once I downloaded it, it comes in an installer. That's a bit odd, but I ran it anyway. It turns out, this is an editor plugin for your computer. Even though it does not take replace the text box by default, XStandard made it very easy to figure out which field IDs needed to be added to use the editor. After adding the needed fields, I fired up the story editor again. After using the editor, I was still left with a bad taste in my mouth. There was nothing particularly special about the editor, certainly nothing worth the pain of installing it.
• YUI Editor: After the pain of XStandard, I was hoping YUI Editor would turn out to be the best editor I'd ever seen. The editor had a beautiful installation. Once I enabled the editor and its dependency, I never had to touch the administration page. Creating a new story was a pleasure. The editor looked, and worked, wonderfully. Everything behaved as expected with one exception. There were no keyboard shortcuts available. This addition would make the YUI editor surpass every editor out there.

My Top 3 Editors

• YUI Editor: Easy to install, easy to use. Even though it doesn't pass either the coder.module or produce valid HTML, from the mindset of someone who doesn't even know what either of those mean, it was the most pleasant editor to use.
• FCKEditor: Even though this was one of my favorites, it's not quite as nice to look at as YUI Editor (superficial, but when you like the actual editing about the same...). It did produce valid HTML, but as I said before, from the mindset of somebody who doesn't really know what HTML is, that is not really too important.
• widgEditor: This one gets it for the sheer simplicity in usage. There are seven buttons total on the toolbar. Even a dog could make a website with an editor like this. It would be nice if there was a bit more that power users could do with it, but for a newbie who just wants to start a website, it is a very friendly way to create a page.

DanW: That's a very interesting assessment -- there are wysiwyg's I've never tried in your list, and I'll go check some of them out on a test site.

In regard to your comments about having to go to a 3rd party site to get the actual editor software, though -- Often the license on the editor portion of the software is not released under the GPL, but perhaps under a similar (or not) license. By policy, Drupal.org only hosts GPL software.

TinyMCE, for instance, is distributed under the LGPL. So, while the drupal.org module that integrates it into Drupal is GPL (and can be placed on drupal.org), the editor itself has to be retrieved from a non-Drupal.org location.

Also, although going to another site can be inconvenient, it does mean that the packaging of the editor software is left in the hands of those most capable to do it -- the authors of it. If Drupal.org hosted all this software in addition to the integrating modules, you have the additional concern of trying to keep the included code "synced" up with its actual code base "across town", so to speak.

Edit: Oops. Forgot a "not" in an important place.

TinyMCE, for instance, is distributed under the LGPL. So, while the drupal.org module that integrates it into Drupal is GPL (and can be placed on drupal.org), the editor itself has to be retrieved from a non-Drupal.org location.

LGPL contains a "GPL promotion" clause, which basically means you are allowed to redistribute it under more restrictive GPL terms. LGPL versus GPL should not be a problem.

However, I do agree that it's a better idea to leave the packaging of the other library to those developers, so that you aren't left having to upgrade your own package whenever the library is updated.

I do see the point in letting people go to the site in order to get the editor, it's just something I didn't like very much. It would be nice if the module could grab the editor directly from the developer's site without having to make the user do it. That could solve both problems, although it might be harder to coordinate with the developers of the various editors.

If you still have your testing environment setup by any chance, something that would be very valuable to add are screenshots for each of the editors, so we can get an idea of what type of interface they provide.

Sure thing. I've attached screenshots for all of them (with the exception of HTMLArea, which I still can't get working)

Great work! This task looks almost complete now.

• To turn it into a d.o handbook page, all of above posts probably need to be converted into a single page (perhaps using a table to display a matrix of editors, XHTML validation, and Coder result).
• It would be great (but not required, since it was not contained in the original task proposal) if the started comparison of editor settings / integration would be completed on behalf of this task (see g.d.o post in the wysiwyg group as mentioned before). I'll let catch/webchick comment on this.
• It seems like http://drupal.org/project/bueditor is missing here.
• I'm unsure if this task should also include bbcode editors, as catch mentioned in #8. A quick search reveals:
  • http://drupal.org/project/bbcode with http://drupal.org/project/quicktags
  • http://drupal.org/project/bbcode_wysiwyg

To turn it into a d.o handbook page, all of above posts probably need to be converted into a single page (perhaps using a table to display a matrix of editors, XHTML validation, and Coder result).

This would be great, but I don't have the permissions to make a table ATM. I did see the comment earlier about joining the documentation team, but I'm unsure about how that would play with Google's GHOP rules. I wouldn't want to disqualify myself to complete a task. ;)

EDIT: I suppose I could just write up the HTML in a separate file and upload it here as an attachment.

It seems like http://drupal.org/project/bueditor is missing here.

Rats. I must've missed it when I went through all those modules. I'll go back and edit the initial post to include that editor once I get it up and running. (I'll add another comment about it so those who subscribe to the issue know when it's done)

I'm unsure if this task should also include bbcode editors, as catch mentioned in #8.

I didn't think it did (obviously) ;) but I think I'll wait for webchick/catch to decide before I start on those. :)

Done! I have now added BUEditor to the lists, and added a screenshot with all the others.

DanW: applying to be on the documentation team has no effect whatsoever on your status as a GHOP student. We've already suggested that several other students apply and they have been granted the privileges necessary to use the documentation input format in their handbook pages. I would suggest you do the same, since it will definitely make the handbook pages look nicer. Just post an issue in the documentation project asking to be a maintainer, and post a link to this issue in your explanation why you want to be a maintainer.

Great work so far!

DanW is now a member of the documentation team. :)

In the back of my mind I had bbcode editors (and bueditor which is along the same lines) included here, but their only official representation is in "etc." so I'll leave it up to DanW if he wants to include them or not. Would be nice, but my own fault for not being explicit.

Tell you what. Once I get finished with GHOP #35 (which is officially closed, but I'm still doing some work on it), I'll do the bbcode editors in here. I'd rather not take on too many things at once, lest I start doing some really poor work. :)

I'll start working on the table with all the results right now and post it here when its all finished. :)

Here's the table with all the data. I do have acouple question before write the rest of it.

1. What category should my handbook page go under? There are a lot more there than I was expecting. :P (My initial guess would be Drupal 5.x -> Basic Content Management, but I'd like confirmation. :)
2. Should the 'overall impressions' be posted in a similar table, or would it be better if I left it as a bulleted list?

The use of the word Dependencies makes me wonder if there should be another row in the table indicating if/where an editor package has to be downloaded from an external site. There are a lot of support requests from people who don't read the documentation and don't know, for instance, that they must download a TinyMCE package from an external (to d.o.) site; perhaps adding an extra line for "External code required" (or something) would be helpful.

ok, I'm subscribing to this thread. I see that nicedit is tested to produce invalid markup. But this should be easy to fix...if true. I agree with the arguments that the author behind nicedit makes, so I'm gonna review the nicedit source and provide douggreen with some developer support. Chx made me aware that it should make use jQuery instead of the current standalone js. Let's see if that can be done.

Fwiw, the dependencies on external modules are also common on the anti-spam modules. Which gives me an idea to propose for a GHOP task …

I agree about the Dependencies portion of the table; it would be useful to note the external dependencies on the editor libraries and optionally link directly to their project pages.

In the table you could say "XYZ external library" for external editor libraries and "XYZ module" for Drupal module dependencies. (Make the italicized "XYZ" text a link to the external site or the Drupal module.) This seems generic enough that the same form could be used when writing other documentation, if there were to be similar tasks now or in the future.

Here you are then. I've updated the chart to link to all the external editors they require.

I'm not sure about nicEdit. It does have a dependency apparently, you just don't necessarily have to download and install it..

From the nicedit project page:

Unlike other Drupal modules that integrate 3rd party components, you do do not need to download anything extra to make this work. This works out-of-the-box because nicEdit hosts the latest stable version of the editor on their website, and Drupal can reference it there. However, you may wish to download a stable copy of the nicEditor and put it in the same directory as the module.

Thanks. I've edited the table to reflect that. :)

I'd like to subscribe here...

As side note - it looks like the wymeditor tested here is very very outdated... see http://www.wymeditor.org/ about a newer demo version. I've read about this Editor some weeks ago, while i tried myself to find a JQuery based Editor... and it looks like this is the one and only available. Ok - it does not have the features of an FCKEditor or TinyMCE (last - looks more bad in the Screenshots as is), but it's jQuery based. And isn't this not something we could get in love? :-)

Are we really judging here by coder module!??? Sounds strange... this is really something we could easily fix. So don't hurt me now, please.

Additional - i think we shouldn't keep TinyMCE out of the last "3" or we could make this to the last 4. I don't use this one myself nor any other, while i'm writing HTML directly in the text areas, but don't test the *most* popular Drupal WYSIWYG editor - i don't know if this is a good decision.

Well, I'm not sure how qualified I am to really give you answers, but here goes anyway. :)

As side note - it looks like the wymeditor tested here is very very outdated... see http://www.wymeditor.org/ about a newer demo version.

Yes, it probably is outdated, but I tested the one inside the Drupal module, which is the one which a very large majority of people who try to use the editor inside Drupal will do.

Are we really judging here by coder module!??? Sounds strange... this is really something we could easily fix. So don't hurt me now, please.

Sure, why not? If the plan is to include one of the editors inside the Drupal core, it would be a good thing to have the module meet Drupal's coding standards. It may not make the editor better, but if it already meets the standards, it means less work for the core devs cleaning up minor stylistic issues.

Additional - i think we shouldn't keep TinyMCE out of the last "3" or we could make this to the last 4. I don't use this one myself nor any other, while i'm hacking HTML directly in the text areas, but don't test the *most* popular Drupal WYSIWYG editor - i don't know if this is a good decision.

Forgive my confusion, but why shouldn't this one be tested along with the others? I hardly think popularity should exclude it. :)

Again, I'm probably not qualified to answer any of these, so I apologize if I'm completely mistaken and/or misunderstanding you somewhere along the way. :)

Sure, why not? If the plan is to include one of the editors inside the Drupal core, it would be a good thing to have the module meet Drupal's coding standards. It may not make the editor better, but if it already meets the standards, it means less work for the core devs cleaning up minor stylistic issues.

Well, it gives us an idea, nothing more from my point of view - if the current maintainers are working on the d.o. standards or not. It is not the problem to get this mostly minor code style bugs fixed - may takes 1 hour or less to fix one module. But catch requested this and i don't like to confuse your here. It looks like finding a module that fulfill this requirement is nearly impossible and i would say - you shouldn't count much on it. I would say 3% or much less in a final decision...

I'm not the writer of this GHOP task... so it might be the decision of the student who took this task, no problem :-)

DanW: just for general fyi and the edification of future generations, can you post additional detail about the steps in the HTML validation tests you ran? I assume (but do not know) that you took a piece of content, applied formatting to it in all editors using the interface, and then examined the output from each editor to see if tags were properly nested, etc.

Do you still have the results from those tests? It would be interesting to see how, and how badly, the tests failed.

(I looked briefly back up through the issue and didn't see this -- if you've already posted it, my apologies.)

Thanks for adjusting that dependency in response to #32.

Sorry, I didn't save the results for the HTML Validation. :( I'll just give the steps I went through.

This first thing I did was check to make sure that the Drupal homepage validated just fine. (It did)

Then, I added some basic content with formatting. Each post contained:

This post was made for Drupal. using the awesome editor EditorName.

Then I took the source of the page, and ran it through the HTML validator. if it came out valid, I listed it as valid. Otherwise, I listed it as having failed.

OK. That sounds perfectly reasonable -- good, even.

I'd definitely include the basics of what you just posted as a footnote to "Valid HTML" in the handbook page. That will help explain, for those that are interested what a "Fail" in "Valid HTML" means.

Are you still planning to do the bbcode/quicktags editors?

Yes, but I have a couple big projects in school that are due this week which are taking up most of my time at the moment. I may be able to do them later in the week, but I doubt it will be before Thursday.

@DanW: Have you created a handbook page for this task yet? If so, I must have missed the link above. But if not, it would be great if you could go ahead and create that so we can wrap this issue up. The parent of the handbook page can be changed at a later time, so don't stress too much initially about which parent to use for this.

What about automatic image resizing and image handling. I personally dont need a file browser, I can just see my users deleting files for blogs, stories, etc that they already downloaded.

I just want a image resize. Set the params (somehow) and then when you upload a file bigger then the specifications, it changes the image to meet these specifications. No need for a file browser.

@GreenJelly: There are (proprietary) image plugins for some editors, and there are Drupal modules that provide image plugins for some editors. IMHO, outlining these is definitely out of scope, and in Drupal, image resizing and image handling really shouldn't be done by an external, proprietary editor plugin. However, the existing Drupal modules are only compatible to a few editors. This is why I am steadily trying to move Wysiwyg API into spotlight.

Great job - very impressive. Would suggest that version number of module be included in the table - so that we know what module version the documentation reflects as some of these modules change on a regular basis.

I also found this: http://drupal.org/project/xstandard

Look at the table more closely. I already did this one. :)

Have you created a handbook page for this task yet?

Not yet. I'll do that asap.

Would suggest that version number of module be included in the table

Sure thing. I'll add that to the table.

Here's the handbook page: http://drupal.org/node/208456

thanks for this most useful of comparisons, I've been painfully trying to review the "wysiwyg" choices for some time now, great job.

seems to be a problem with the handbook page tho... check out the screen shot I attached below. Happens with both FF2 and IE7. Not sure how to fix it though, unless the table orientation is switched.

Some thoughts I had after checking out the documentation page and the comments above:

# Consider writing an introduction of a paragraph or two to give someone an idea of what the documentation page is about. You can probably borrow from the original task description.

# Consider including the "Overall Impressions" from comment #11 above in the documentation page. That background information could be useful to anyone "shopping" for a WYSIWYG editor.

# The original task description called for a separate post to the wysiwyg group "My Top 3 Editors," but you may want to include the information in the documentation page as well or at least link between the two.

# The screenshots from comment #16 above are also crucial for the documentation page.

# You may want to add Comparison to the title of the page (maybe "Comparison of Drupal 5 WYSIYG Editors") as it's more descriptive and will make it easier to find later.

# Excellent work!

Sorry I haven't been responding to anything. Apparently my DNS got messed up somehow and drupal.org was adversely affected.

# Consider writing an introduction of a paragraph or two to give someone an idea of what the documentation page is about. You can probably borrow from the original task description.

Sure thing. This shouldn't take too long to add. :)

# Consider including the "Overall Impressions" from comment #11 above in the documentation page. That background information could be useful to anyone "shopping" for a WYSIWYG editor.

Alright. I wasn't sure if that info was intended to be on the handbook page and erred on the side of caution. :)

# The screenshots from comment #16 above are also crucial for the documentation page.

With the table markup - probably best to make it vertical, so it's just four columns across the top and each editor as a row. The write-ups and screenshots are really good, so I'd put the image and paragraph below the table, and maybe make the project names in the table go to #anchors on the page, with a url to the project in the write-up itself.

Agreed. I mostly just copied and pasted the table to get a start on the handbook page - I had planned on being able to access it over the past few days. :)

# You may want to add Comparison to the title of the page (maybe "Comparison of Drupal 5 WYSIYG Editors") as it's more descriptive and will make it easier to find later.

Excellent suggestion. :)

Alright, I've made a lot of changes to the handbook page.

I've added catch's and Matt V's suggestions to the page.

http://drupal.org/node/208456

I have the permissions to attach files, but when I try it gives me an unspecified error.

Still gives me the error. I'm not sure what's going wrong - an "unspecified error" isn't very helpful. ;)

whizzzywig is listed as not having icons... it does allow for icons it just happens not to be well documented on the readme file.

It is recommended to download the buttons.zip package from the Whizzywig download site, and place the contents in this folder.
- taken from whizzywig/whizzywig/buttons/README.txt

The wysiwyg is also dynamic enough that you can add new buttons via the admin ui and upload icons for them.

also the link to whizzywig is wrong the link says http://drupal.org/project/whizzywhig but it should be http://drupal.org/project/whizzywig

If you could fix the links, add a corrective note about whizzzywig

Fixed both of the problems. Thanks for uploading the pictures. :)

also the link to whizzywig is wrong

Oops! Fixed that as well.

add quicktags (etc.?)

Added quicktags and BBCode Editor. I've attatched a screenshot here, since it still doesn't like me uploading them to the handbook pages.

EDIT: I got the screenshot to upload somehow. Yay. :)

. Since you've posted the handbook page first, you could probably just announce this in the wysiwyg group on g.d.o.

This is an odd problem, but i cannot figure out how to put a new posting on the group.

Here's the issue for HTMLarea: http://drupal.org/node/211194

and one for Quicktags: http://drupal.org/node/211197

DanW,

If you don't already have an account on groups.drupal.org, you'll need to sign up for one first (groups.drupal.org and drupal.org require separate logins). Then, I believe you need to Subscribe to the wysiwyg group before you can post there. You can do that by clicking on the "Subscribe" link in the upper-right corner of the pages within that group. You should then see a new box in the upper-right. Click on "Create Story" and enter your post.

Thanks. For some reason I was thinking 'subscribe' was an RSS feed for the group. :)

(groups.drupal.org and drupal.org require separate logins).

You can actually use the Drupal.org account by logging in as YourDrupalUserName@drupal.org for the username.

...and here's the post: http://groups.drupal.org/node/8252

I think this was accidentally closed.

Oops! Sorry about that.

I know this would not be covered by the ghop portion of this, but what should we do as these modules update themselves? Whizzywig module for instance has made some recent changes (yet to be released in a final form) that will make this page no longer correct in terms of the whizzywig experience (buttons are now to be included). So when this happens and when other modules come along, or are changed how do we update this page?

The reason i ask is this seems like a personal account.

And secondly, the link to whizzywig above the description still goes to http://drupal.org/project/whizzywhig which has an extra h, making it wrong.

understood, this particular page however seems to be told more like a first person perspective, thats the only thing that throws me off. But if anyone can update, thats works for me.

And secondly, the link to whizzywig above the description still goes to http://drupal.org/project/whizzywhig which has an extra h, making it wrong.

Very odd. My computer links it to the correct page. Are you sure you're not loading an old version from your cache or something?

understood, this particular page however seems to be told more like a first person perspective, thats the only thing that throws me off. But if anyone can update, thats works for me.

I also thought this was odd (and I wrote it!). When I first wrote it, I wasn't under the impression that the general impressions were for the handbook page, so I wrote it as I experienced it in the first person (which made sense to me at the time). When I put it on the handbook page, I wondered if this would be a problem, but nobody seemed to mind it in the slightest, so I left it alone.

1) Thats because, I joined the docs team, and fixed the link ;) (you can check the revision log)
2) While not consistent with most handbook pages, the first person account i think works for this page, it just makes updating this page a little awkward.

IMHO, I grew to like Kupu quite a bit when I was in the Plone world, before I became Drupal-enlightened. It's a personal mission of mine to find somebody somewhere (inside of Acquia, or not) to port Kupu to Drupal.

It isn't obvious that this will go well.

• Kupu likes to make it easy to handle image insertion. But Drupal has a ways to go before it handles image file management well enough for Kupu to grok it.
• Kupu has a nice facility for handing intra- and extra-site hyperlinks. But again, Drupal has some things about it that might make this tricky to port this capability.
• Kupu is also known to not work on Safari. Which sucks, since I'm a Mac/Safari guy. But I'd use FFox more often in site editing to get Kupu if it worked in Drupal.

If somebody takes on a Kupu port project, please contact me. I'll see what I can do to add some form of resources.