You are not logged in.
I commented those lines out in changeset:519, and reopened ticket 543, which R496 was supposed to fix.
Try using the GetHtml plugin. It takes care of all this.
You might be able to do it as a plugin. Just put all the modified functions into a plugin that overwrites the original ones. That's essentially what I did with the GetHtml plugin. In this case it sounds like it might be a pretty big plugin, but it ought to work.
If you are using the GetHtml plugin, make sure you have the latest version. I posted an update to it last week that fixes a problem that sometimes occured in IE with self-named anchors.
I stumbled across this article recently:
http://www.brainjar.com/dhtml/menubar/
that includes a workaround for this problem. He puts an iframe behind the menu to mask the dropdown. It's a fair amount of trouble to go to, but he claims it works. For what it's worth....
InnerHTML returns all the html under a given node in the document, not including the tag for the node itself. OuterHTML is an IE-only property that returns the html including the tag for the node.
As to the initial observation about empty attributes, it's not that GetHtml inserts them, but rather they are inserted by the _createLink function and GetHtml fails to remove them the way the built-in getHTML does. Changing these lines in _createLink:
a.target = param.f_target.trim();
a.title = param.f_title.trim();
to
if(param.f_target != '') a.target = param.f_target;
else a.removeAttribute("target");
if(param.f_title != '') a.title = param.f_title;
else a.removeAttribute("title");
would be one way to fix it, but it probably would be a good idea to strip empty attributes in GetHtml anyway. I'll look at doing that, just one more regular expression....
Perhaps more important than the speed is that GetHtml produces XHTML-formatted code, and it supports some tags that are not handled properly by the built-in method. Specifically, Flash is supported (in <object> and <embed> tags), scripts are supported, and formatting of the text within <script> and <pre> tags is preserved. Also, the HTML output is formatted and indented for both IE and Mozilla-based browsers in GetHtml, where the built-in method only formats IE. Not everyone needs all these improvements, and GetHtml could still be viewed as experimental, although I am using it in a production environment with no problems.
That indicates that the problem is not in the plugin or your config. You seem to be using the variable eeditor for two different purposes, one as the name of the editor object, the other as the name of the textarea. When you execute the line 'extendedbody=eeditor.getHtml();', does eeditor refer to the textarea? If so, that's your problem. getHTML() only applies to the editor object.
Does it work if you *don't* load the GetHtml plugin?
Nobody is working on it. There are no plans to do so, unless a keen developer with a mac comes along, or somebody buys me a mini-mac, or konq gets a 100% compatable content editable system.
I might take a crack at it, but probably not until after we get xinha 1.0 released. And I get a whole bunch of other stuff out of the way. Unless someone gets to it before me...
Dortamur: I don't like those table popups either, waaay to complicated for the average joe. Sometime in the future a simplified table operations plugin will be made.
I have done this - restructured TableOperations to use the same architecture as the other plugins. It's got a bit of stuff in it that is custom for my application. When I get a spare minute I'll strip that stuff out and post my code.
The original Forms plugin that I submitted in ticket #256 does something like this. It adds just two buttons to the button bar: one to create the form and the second for all form elements. The pull-down select list is in the popup window. This version never made it into the Xinha distribution; it was rewritten by gocher, who split the form elements into separate buttons, which, as you note, takes up a lot of space. My version is still available from ticket 256 if you want to play with it.
Does anybody know why Stanislas is using HTMLArea from mishoo instead of Xinha?
It looks like he is customizing a version of HTMLArea 3 for use as a module in Typo3, a CMS. Probably not related to whatever Mishoo is doing.
I found the problem, and a very simple fix. It's posted under the ticket:
And the icons for TableOperations plugin:
Most of these new buttons look great, but I find some of the new table operations buttons less intuitive than the ones they replace, in particular, the 'insert before' and 'insert after' buttons. It's not obvious which is which without studying the colors. Could you rearrange the elements along the lines of the original buttons, so the layout provides additional cues?
Also, the 'table properties' button is identical to the 'insert table' button. How about superimposing a pencil, say, or a magnifying glass over the 'properties' buttons?