Hi.
How is CarriageReturn suppose to work?
It' would be nice if FCKeditor produced the same in IE and FF (Gecko). But it does not.
Even if I set:
FCKConfig.UseBROnCarriageReturn = false ;
Firefox still insert "<br />".
IE insert "<p> </p>" on CR and "<br /> on SHIFT+CR.
Is this supposed to work similar in IE and FF (Gecko) or not?
If not, is this issue going to be fixed or is there a patch available?
How is CarriageReturn suppose to work?
It' would be nice if FCKeditor produced the same in IE and FF (Gecko). But it does not.
Even if I set:
FCKConfig.UseBROnCarriageReturn = false ;
Firefox still insert "<br />".
IE insert "<p> </p>" on CR and "<br /> on SHIFT+CR.
Is this supposed to work similar in IE and FF (Gecko) or not?
If not, is this issue going to be fixed or is there a patch available?
RE: How is CR (CarriageReturn) suppose to wor
From reading the changelogs, it appears we (the royal we
had to change the way gecko does the CarriageReturn stuff. A nifty feature was added, but had to be rolled back, because of a new set of bugs/complications. K sir rah, sir rah. It sucks but it looks like there just needs to be more work done in this area.
I need less coffee... :d
Also a factor is the new firefox... and there has already been some questions raised about how to handle different versions. I like the idea of encouraging people to use the latest versions of browsers. It is a "good thing". Sadly, not all can do it, for various reasons. So what do we do? Alert boxes with warnings? Just plain deny people using "know-wonky" browser/versions?
Personally, and I hate this as much as the next man, but it really is still true: I think the little "best viewed with" caveat should still be used (if you need it!).
Bah. It goes against the ideals of this project, but until things like the <p> vs <br> and others are solved, if you really need that fine grain controll over the input, I'd suggest "suggesting" your users use a certain browser/version.
Either that, or make some killer regular expressions that somehow know which <br>s to change to <p>s and whatnot. <--- this is hard and not 100% reliable, last I checked.
Not a good solution, but lets face it, browsers are different.
Depending on philosophy, by "working around" bugs in browsers, we put less pressure on the browser folks to actually fix the bug/behavior, and thus more work on us to maintain our "workarounds".
Conversely, some think differently, and I see good points in many different thoughts, and am of the constitution of: "best" depends on context, so I don't lean too far any way.
Sorry this wasn't a post to say: eureka! here's a patch! :-/
For what it's worth, it's obviously being worked on, just judging by the changelog (what's new), but it is also obviously difficult, or it would be in there.
Interesting stuff to think about tho... interesting... sorta deep mood right?
RE: How is CR (CarriageReturn) suppose to wor
One question though.
Is it not possible to implement some sort of event listener ... and then when the CR key are pushed down then insert either "<br />" or "<p> </p>" depending on the setting in the ...config.js file.
In IE:
document.onkeydown=docKeyDown;
And then use: e.keyCode
In FF (gecko):
document.addEventListener ('keypress',docKeyDown,true);
And then use either:
e.which or e.keyCode
I belive both gives same keyCode for CR in gecko.
And then eventually use for IE:
e.cancelBubble = true;
e.returnValue = false;
And for Gecko:
e.preventDefault();
e.stopPropagation();
to prevent whatever is default inserted on CR and then force either "<br />" or "<p> </p>"
I guess it may not be that simple though... because if it was then it would probably be there allready.
What exactly is the problem that this is not doable?
Regards
RE: How is CR (CarriageReturn) suppose to wor
Ref. the release on ver 2.1.1:
In the /editor/_source/internals/fck_1_gecko.js file (extract of some of the code, see end of post) I found a wrong reference to a variable in FCKeditor:
One place it says:
FCKConfig.UserBROnCarriageReturn
I belive it should be:
FCKConfig.UseBROnCarriageReturn
Could this be related to the bugs that where reported when the code was implemented in the 2.1 version?... and that laiter was commented out.
Regards
***********************************
Copy of some of the code below:
***********************************
var oOnKeyDown = function( e )
{
// FCKDebug.Output( 'Which Key: ' + e.which ) ;
// START iCM Modifications
/*
// Need to amend carriage return key handling so inserts block element tags rather than BR all the time
if ( e.which == 13 && !e.shiftKey && !e.ctrlKey && !e.altKey && !FCKConfig.UseBROnCarriageReturn && !FCK.Events.FireEvent( "OnEnter" ) )
{
e.preventDefault() ;
e.stopPropagation() ;
}
// Amend backspace handling so correctly removes empty block elements i.e. those block elements containing nothing or
// just the bogus BR node
if ( e.which == 8 && !e.shiftKey && !e.ctrlKey && !e.altKey && !FCKConfig.UserBROnCarriageReturn && !FCK.Events.FireEvent( "OnBackSpace" ) )
{
e.preventDefault() ;
e.stopPropagation() ;
}
*/
// END iCM Modifications