So lots of applications go and edit the CSS styles that flow into these subtrees, or do serious by-hand manipulation of the DOM in response to various events.

For example, drop-and-drop image manipulation is typically done by adding an image node with custom CSS and js behavior applied, inside the editable region. Similar story for highlighting, annotations, etc.

That kind of thing would be impossible with a black-box editing component.

What exactly is deep integration between editor and DOM needed for? In my (doubtless hopefully naive) imagination we would just drop in an editing component and it would spit out HTML or XML or whatever to the page.

Thanks for the ping . Yes, a non-sucky editing component is something we considered right from the start for Gears.

The main difficulty from Gears’ point of view is the deep integration between the editing features of current browsers and the DOM. Web applications such as gdocs have come to rely on such integration, and it would be difficult to supplant it with Gears.

We could do something like a black box editor, more like Editize or the way some authors use Flash. However, it’s not clear this would be useful to developers.

A harder, but ultimately better solution to this problem is to just lobby the browser vendors to put serious resources on fixing it. As I understand it, things are better in Firefox 3, partly because the contenteditable attribute has finally been implemented. (docs has not been upgraded to take advantage of it though).

Biggest beef I have with Apple apps right now is crappy address book/ical integration. They just don’t work together like they should.

http://extensions.services.openoffice.org/taxonomy/term/50

One of them supports Zoho too.

And, as an added benefit, it should work well with Prim