Xinha Discussion Forum

There is none. We don't have much in the way of user documentation, let alone API documentation.  The code is commented though.

Making plugins is not really hard provided you can program in Javascript in an object oriented manner (if you cannot, then learn that first), just look at some of the small ones to get the idea, InsertWords (very simple), InsertSmiley, CharacterMap, BackgroundImage, and for a bit more look at SuperClean, and Linker.

Update to the latest from the subversion repository, should be scrollable in that.

This is a browser feature, I do not believe we can alter it.

A while ago I created a fork in the SVN for initial Opera compatability - you can check that out (/branches/opera) to see what changes I've made in that; but this was for the first preview release so may not work in the Beta.

Yes.... to an extent.  But when you have to work around browser problems/differences you really need to know, "is this IE in quirks mode" or "is this Opera version xxx with the yyy bug" - you can't just look to see if a certain feature is there sometimes.

I havn't posted here much lately (ok, for quite a while) because I just havn't had time to work on Xinha   Have a project coming up though that might allow me some time for the X (actually, I really want to get it working in Opera 9 now it's in beta -- I use Opera almost exclusively nowadays).

Anyway, a toolbar cleanup has always been "on the books", for the simple reason that plugins adding buttons to toolbars is completely haphazard at the moment.  Like you say, I would like to see set named groups of toolbars which plugins can, well, plug into; I think I've mentioned this either in a post here or in a ticket before.  I think this could be achieved without too much trouble because we already have toolbar groups in a fashion, they just are not named.

The styled-selects for fonts etc is something I've wanted for a while.  A friend of mine was working on it for a while but never was able to get it to work quite right cross-browser.

As for tabs of buttons, I think the panels system could be used in this regard, perhaps even a plugin which replaces/extends the existing toolbar creation with a panels-based one.

I have reservations about that new Word toolbar screenshot, personally, I don't like it.  But then I'm a programmer, not a joe bloggs who actually uses Xinha, so I'm not the best person to design the toolbar.

Select lists are "windowed" elements in IE, they always appear on top.  At least last time I looked there is no solution (aside from hiding the select lists, but that's a job for your menu code, not Xinha).

My guess is that doc.Documents(document.all.hello.value).Content is returning plain text, you'd  have to find the documentation of the Word ActiveX object and see if you can get it to return HTML which you can then insert.

The browser will be doing that, not much we can do to stop it.  Script in Xinha (or any online HTML editor) will be limited at best.

It's a bug in Firefox, head on over to bugzilla.mozilla.org

I believe the browsers enforce link differentiation when in an editable area (such as Xinha)...ie it's not Xinha changing them, it's the browser.

The only reason is would add head/body is if you have it in FullPage mode, which is intended for editing, well, Full HTML Pages with head and body.  Take it out of FullPage and your troubles will be gone.

Divs inside paragraphs is invalid (block within block), if you write invalid HTML, be happy with what you get out   To get teh current element, have a look in htmlarea.js, there is a method there to do that as I recall.