You are not logged in.
Is the HTML page you are including Xinha on in Standards or Quirks mode?
A common issue I've found is incorrect nesting of the form element, specifically people often nest it between <tr> tags or similar invalid locations. This will cause problems for you.
i.e <table><form><tr> is invalid and very bad, <form><table><tr> is OK.
Xinha doesn't work in Safari at all, to my knowledge
No Mac around here, so no Safari testing.
You are outputting stuff before the session headers are output. Have a PHP developer install it for you if you don't understand PHP.
Because the browsers implement it differently internally. Firefox specifically uses the old presentational tags (I/B), while IE does the right thing and uses proper semantic markup (em/strong).
Put it in your textarea.
I have a feeling it does nothing useful and should be removed. I think it was something I started working on, long ago (when it was still HTMLArea) and never finished.
It may be, although I'm sure i've adjusted it once already.
You need to adjust the height value in the CSS file, at least that's the easiest way. open up skin.css for the appropriate skin you are using and find the height value for .htmlarea .toolbarRow, increase it a bit.
Depending on your browser you may need to load the CSS file directly in the browser to force it to flush through the cache, CSS files have a tendancy to get stuck sometimes.
Please provide a URL where we can see the problem and try it out.
offsetTop/Left is the offset from the parent element isn't it? I think you should add up all the offsetTop's/Lefts back to the root element and that would give what you want.
Sure it's called "keeping your own working copy of the SVN setup just how you like it and then doing an svn update to bring in just the changes to what you want to keep and then doing an svn export of the working copy so that you can put a clean version without the svn stuff into your production systems".
Kinda a long name.
Not presently.
It used to be, perhaps still is for IE, that selects ("dropdowns") cannot be covered by layers, they always show through. If it works in Firefox, and not IE, blame IE for not fixing that very old problem. Check in the latest IE you can get hold of.
You'll have to play around with those settings, not sure what will work if anything. It's the browsers that stuff it up originally, Xinha tries to fix thier mistakes where we can.
Modify your plugin to accept the available variables in the configuration of the editor.
Post a URL to your attempt, we can't help with so little information.
Common causes...
1. You are submitting the form directly using form.submit() (or similar), which will not call the onsubmit() function of the form, which means that Xinha never gets told to save the HTML into the textarea. If you are not submitting with a submit button, then make sure you call form.onsubmit() first.
2. You have incorrectly nested the form tags inside tables, or table rows... eg <table><form...>.....</form></table> or <table><tr><form...> ... </form></tr></table>. This is invalid HTML, and sometimes browsers will not throw events (or something, whatever Xinha fails on it), you should use valid HTML, specifically form tags may not be children of table, or tr.
/path/to/your/stylesheet.css
BTW: I don't think the popup editor is available any more, it was so buggy it wasn't worth keeping around. You could develop a plugin to do that.
You should be able to dynamically modify the code without touching the Xinha files.
Is it possible to hide (display:none) the map? If so, then you could modify the FullScreen button to hide/show the map, that'd be the easy solution.
As the others have said, Xinha is, IMHO, far and away better than HTMLArea was, HTMLArea was flakey as anything, Xinha isn't. I use the trunk at various revisions in my own production systems.
Version 1.0 is something I'd like to see happen before April. After that we can start structural changes to improve speed, lower memory use, Safari and Opera support.
Plugin objects may contain a method onKeyPress which receives a standard event object. You should also be able to define an onKeyPress for the textarea in the usual manner for HTML.
Search the forums, this has been asked and answered recently