Open letter to Frederico Kaldeira Knabben

Thanks for that reply.

When I saw your anonymous answer I thought there was a solution within standard FCKeditior.

To bad this is not in standard version.

Nice of you to show us a workaround.

FCK ... this would be nice to have in FCKeditor without having to add custom code.

Okay. I thought I was getting closer to an integration of FCKeditor in my CMS system.

Here is my latest findings and I'm not very happy about it:

There seem to be compatibility issues between for example IE and FFcaused by which tag's are beeing used for different basic stylings (buttons clicked). And here is the bad news. If you let say style (using the buttons below) the text in FF and then save to database and opens same text/html in IE then you may or may not be able to style or "destyle" the same text in IE using the same buttons that where used in FF. There are also problems the other way around.

Up to now.... I thought I was close to be able to integrate FCKeditor in my system... but then I discovered this ugly stuff yesterday. And I do not like the idea to tell my users that if they start editing with for example FF, then they will have to stick with FF otherwise they will not be able to edit the content.... And I would probably have to say that they might not be able to edit the text in future in the browser they started with....

NOW.. Why does FCK not list these issues so every new user do not have to accidentially find them themselves......?

And IS IT POSSIBLE to use the same tags for the same styling (se buttons listed below)?
If it is I think someone should give priority to make different browsers use same tags for same stuff. This will probably save a lot of people for hours of vasted time and frustration. And will probably also be easier to integrate FCKeditor with classes.

I visited:
http://xinha.python-hosting.com/
They are using IFRAME as well to display the editor.
All these problems I talk about here work like a charm there (same tags are used for same styling (basic buttons), and (Note: in FCKeditor there is a problem in IE with DIV where you use WIDTH property, where you cannot access image or select text by left-click and drag) ... here at xinha you can access the images within the DIV and you can also left-click and mouse drag to select text in same type of DIV.

Okay.. I have not downloaded xinha it and tried it out locally yet (only tried the demo on their site on IE and FF).
And I do not know if they handle CSS as nicely as FCKeditor.. but I will check it out.

Despite my complaints here... I still want to use FCKeditor if these issues can be fixed.

But I think this site as well as http://www.fckeditor.net should rename FCKeditor to RC3, and list issues like I have in my post here so new people that are considering implementing FCKeditor in their CMS system or whatever quickly can find any serious issues there might be and also if someone are working on it.

Another thing....
This way of showing what's going on is nice:
http://xinha.python-hosting.com/roadmap

BELOW ARE THE NEWLY FOUND (for me) COMPATIBILITY ISSUES between IE and FF.

The inserted tags using FF vil for some of the buttons change when using:
FCKConfig.GeckoUseSPAN = false ;
But it will still differ from what IE uses and will/can produce incompatible results ref. above text.

Examples:

Bold button:
IE uses STRONG tag
FF uses SPAN + font-weight:bold
or FF uses B (if GeckoUseSPAN = false)
If you use bold button in IE and laiter try to change same text to no bold using the same button in FF then it will not work.
If you do it the other way around, IE recognice the tag and are able to remove it (that if is FF are usin B tag), if FF are using SPAN then IE are not able to remove tag using the Bold button.... but you can remove it by deselecting by using the "custom bold" in style dropdown (headace.. intuitive .. yes .. no).

Italic button:
IE uses EM
FF uses SPAN + font-style:italic
or FF uses I (if GeckoUseSPAN= false)
If you apply italic in IE and opens the text in FF then FF does recognice the EM tag (italic button highlighs) but you cannot remove it by using the button, but you can select text and deselect using the "custom italic" from style dropdown.
If you apply italic (SPAN) in FF and opens in IE and try to edit, then IE recognice the style and highlights italic button... but you cannot remove the style... not by using the button and not by deselecting using "custom italic" from style dropdown.

Underline button:
IE uses U
FF uses SPAN + text-decoration:underline
or FF uses U (if GeckoUseSPAN = false)
If FF uses U then its compatible between the two (why should it not).. and if FF uses SPAN....

Strike trough button:
IE uses STRIKE
FF uses SPAN + text-decoration: line-through
or FF uses STRIKE (if GeckoUseSPAN= false)

Indent right button:
IE uses <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
FF uses <blockquote>
Here they are compatible between the browsers. But if you apply the style in IE and then try to remove in FF then the text are just moved outsidet the blockquote tag and the tag itself are not removed.

RightJustify
IE uses <p align="right">
FF uses <div align="right">
Both tags work in both IE and FF, but is there a reason for using different tags when used in different browsers?

The compatibility issues may or may not be experienced when you use the buttons below, depending on setting in fckconfig.js and depending on how you combine the styles applied by buttons below.

Bold
Italic
Underline
Strike trough
Decrease Indent
Increase Indent
Justify buttons

Hi again and thanks to FCK for replying, as well as others.

Here are two examples of text and image inside a DIV.
The first one does not have the WIDTH property set and both text selection by left-click and drag as well as image editing (edit properties) are working great in IE.

In second DIV I have set the WIDTH property for the DIV and that is what seem to trigger the problem. Now ... selecting text is not easy in IE.. you cannot left-click and drag to select text, and you cannot right-click the image to edit its properties, nor can you select the image.

The problem I reported earlier about problem with nesting DIV's was a mistake by me. It now looks like the thing causing the editing problems in IE has something to do with the WIDTH property in the DIV.

Try the example code below in IE and you will see how it works. Just added some other styling so it should look a little better.

I have also experienced problems in IE with for example a floating div (float:right or left) and also with the WIDTH property set;
If I edit the text to the left /right of that DIV then the DIV somtimes starts to hide some of its lower parts. See second example for this issue also.

Okay.. since I have your attention FCK I also want to mention how much I would like to see four new properties added to the image properties dialog box:
margin-top, margin-right, margin-bottom, margin-left
which gives much more precise control over layout than the VSPACE and HSPACE.

Also much wanted is a possibility to add a table with TH cells at top. Could be implemented by one more option:
Add table header... or whatever.

Okay.... DIV issue examples below....

<div style="PADDING-RIGHT: 20px; PADDING-LEFT: 20px; FONT-SIZE: 12px; PADDING-BOTTOM: 20px; COLOR: black; PADDING-TOP: 20px; FONT-FAMILY: arial; HEIGHT: auto; BACKGROUND-COLOR: #aaaaaa"><img height="70" alt="" hspace="4" src="http://www.fakeimage.com/fakeimage.jpg" width="50" align="left" border="2" />Try to select select some text in IE. It is easy.<br />And if you right-click the image you can edit its properties. </div>
<br /><br />
<div style="PADDING-RIGHT: 20px; PADDING-LEFT: 20px; FONT-SIZE: 12px; FLOAT: left; PADDING-BOTTOM: 20px; WIDTH: 50%; COLOR: white; PADDING-TOP: 20px; FONT-FAMILY: arial; HEIGHT: auto; BACKGROUND-COLOR: #888888"><img height="70" alt="" hspace="4" src="http://www.fakeimage.com/fakeimage.jpg" width="50" align="left" border="2" />Try to select some text in IE. It is NOT easy.<br />If you rightclick the image in IE you can NOT edit its properties.<br />The only difference from the first DIV is that this DIV has the WIDTH property set. </div>
Insert cursor after last letter in this sentence and hit CTRL multiple times

I had earlier, yes.

But I did not inlcude the samples... I will update the bugreport with the samples.

Really hope you can fix these issues before next release !

Keep up the good work

To Andre Schild:

Have reported my findings.
Many of my findings where really old findings which had earlier (some long time ago) been reported in the buglist, but with no one assigned the bug and with no comments from developers if those issues will be handled, as well as some of them are not easy to find in the buglist either.

Then when you visit. http://www.fckeditor.net and see that there is a final version out, where none of the issues I have raised here are mentioned then one might belive it's a working version...... when the reality is that there is issues....

Beeing an opensource project does not justify to not give out relevant information about the current state of the project in a compact and readable way. In my opinion that would benefit both FCK, the developers and end users.

I did not produce my issues here if I did not belive (was hoping for) that some of the developers might fix them.
Reading the buglist gives me the impression that the developers do not take the reported bugs seriously... many of the serious bugs does not even get a comment from the developers (even after a long time they stand there without comments, and without anybody assigned to them)

Did you read my last post in this thread.?
What are your opinion on those issues.?

Have said it before.... I belive the developers are doing all they can, and I belive in this project.
But I also belive that when lots of people put lots of hours in testing FCKeditior and report their findings, then the developers should take the time to give some feedback to the guy that reported the bug / feature request (by responding to that bugreport). This is not only feedback for that guy, but for all the rest of us as well, as well as the newcomers.
And by putting all the issues that are to be dealt with in near future in one please in a readable format would only benefit this project...

My reason for listing my issues here as well, is because of that lack of information, and to hope to hear a word from the developers if the issues that I have listed here are to be fixed or not, and hopefully when....

All the best

Hi again.

I got this hint from an anonymous one on how to enable dynamic style class switching for the editor body tag.

******************************************
in fckconfig.js use the lines
------------------------------------
FCKConfig.EditorAreaClassName = 'classname';
FCKConfig.EditorAreaID = 'id';
------------------------------------

On the page that you use it you can do
FCKEditor.Config['EditorAreaClassName'] = 'classname';
******************************************
the hint above was posted at:
http://sourceforge.net/tracker/index.ph ... tid=543656


I have tested this and manage to switch the className for the body tag using:

function switchClass(theclass){
var oFCK;
if (navigator.appName=="Netscape")
oFCK = MyTextarea___Frame.contentWindow;
else
oFCK = MyTextarea___Frame;

oFCK.FCK.EditorDocument.body.className = theclass;
}

I created two buttons in my page, each with a call to the function above with the class name as argument.

This actually works nice even without any use of:
EditorAreaClassName in the fckconfig.js file.

What I need now is a way to set the className when initializing the editor. And I need to do it from the page that contains the editor and not fckconfig.js file.

I tried this:
oFCKeditor.Config['EditorAreaClassName'] = 'divtest';
and this:
oFCKeditor.Config.EditorAreaClassName = 'divtest';

before this line:
oFCKeditor.ReplaceTextarea();

None of those two lines seemed to work.

Anyone with an idea how I set the className of the editor BODY at startup of page?