execCommand problem

[abdalimohd]

hi all,

i m developing an html editor for my web page since i cannot trace out the enter key press for the available html editors for asp.net app. now i have done everything that i need with this editor but the execCommand doesnt work with IE, it works perfectly with FF. when i alerted myEditor.docume nt.queryCommand Enabled('Bold') [ for bold command ] i get false for IE where myEditor is the Iframe id which is used in editable mode. please help me...
i will post the whole code here.
//html part
[HTML]<IFRAME name="navoCHatE ditor" width="100%" height="100" onfocus="setKey pressHandler(wi ndow.frames.nav oCHatEditor, keyPressHandler )" ></IFRAME>
[/HTML]
//js part

[CODE=javascript]function keyPressHandler (evt) {
evt = evt || window.event;
if (evt) {
var keyCode = evt.charCode || evt.keyCode;
//output(evt.type + ': keyCode: ' + keyCode);
if(keyCode == '13')
alert('Enter Key pressed');
}
}

function setKeypressHand ler (windowOrFrame, keyHandler) {
var doc = windowOrFrame.d ocument;
if (doc) {
if (doc.addEventLi stener) {
doc.addEventLis tener(
'keypress',
keyHandler,
false
);
}
else if (doc.attachEven t) {
doc.attachEvent (
'onkeypress',
function () { keyHandler(wind owOrFrame.event ); }
);
}
else {
doc.onkeypress = keyHandler;
}
}
}




function initEditMode (frame) {
if (frame.document ) {
frame.document. designMode = 'on';
}
}

window.onload = function (evt) {
var editFrame = window.frames.n avoCHatEditor;
setKeypressHand ler(editFrame, keyPressHandler );
initEditMode(na voCHatEditor);
};

function RunCom(what) {


//*************** *************** ********

if (navoCHatEditor .document.query CommandEnabled( what) == true)
{
navoCHatEditor. focus();
navoCHatEditor. document.execCo mmand(what,fals e,"");

}
else
{
alert('command' + what + ' not enabled')
}

}

function ForeColor(col)
{
navoCHatEditor. document.execCo mmand("ForeColo r",0,col);
navoCHatEditor. focus();
}

/////[/CODE]

thanks,

ali

[acoder]

Welcome to TSDN.

See this link (not exactly what you want, but it might help).

Usually, it's the other way round (execCommand doesn't work in Firefox).

[cBe9999]

I was having the same problem - I got around it by placing a button inside the color palette where each colour is and styling it with CSS.

The onClick event on "normal" DOM elements takes the focus away from the contenteditable region whereas button and submit input types do not (though obviously buttons are preferrable in this case to avoid having to keep adding return false statements into your functions).

[deuce789]

Solution:

You can use the following attribute to get around this problem.

 <div unselectable="on"></div>

This attribute can also be applied to table cells, etc etc

[drhowarddrfine]

There is no such thing as an "unselectab le" attribute.

[acoder]

There is no such thing as an "unselectab le" attribute.

That's what I thought too. Now I don't need to check because the Doc has spoken.

[iam_clint]

i would also like to confirm there is no unselectable attribute..


This may be a custom script attribute.

[deuce789]

There is indeed an attribute called unselectable, which was developed especially for problems like this, and was introduced in internet explorer 4.

http://msdn2.microsoft.com/en-us/library/ms536419.aspx

I actually have had the exact same problem myself with developing rich text editor related stuff.

This attribute is only valid in internet explorer and Opera (From version 7 onwards i believe), however it fixes the problem, the html code may not be valid as per the w3c standards, however the output from a basic rich text editor using the default browser behaviours for execCommand most definitely also will not be w3c compliant, so i dont think thats an issue here :)

There are other properties that do the same thing if this problem appears in other browsers such as :

onselectstart="return false;" (safari/opera)

and

style="-moz-user-select:none" (mozilla).

So, there you go :)

[acoder]

This attribute is only valid in internet explorer and Opera (From version 7 onwards i believe), however it fixes the problem, the html code may not be valid as per the w3c standards, however the output from a basic rich text editor using the default browser behaviours for execCommand most definitely also will not be w3c compliant, so i dont think thats an issue here :)

I guess you're correct in that respect.

[drhowarddrfine]

the html code may not be valid as per the w3c standards

It's invalid because it does not exist in the standard. There are many things that only work in IE but if you want your markup to work in all browsers then you need to follow the standard and not Microsoft.

[deuce789]

WYSIWYG editing itself was originally a microsoft only thing and in itself is "violation" of w3c standards, and from browser to browser the way it acts can be very different, so are you saying we shouldnt use WYSIWYG editing at all, because in this case it seems everyone and every browser maker followed microsoft and not the standards :-)

[drhowarddrfine]

WYSIWYG editing itself was originally a microsoft only thing

It was not. It became popular with Xerox PARC in the 70s.

and in itself is "violation" of w3c standards,

Editing and wysiwyg has nothing to do with the W3C.

are you saying we shouldnt use WYSIWYG editing at all, because in this case it seems everyone and every browser maker followed microsoft and not the standards :-)

Since editing has nothing to do with the W3C, the last statement makes no sense in this context. Except "every browser maker followed microsoft and not the standards" is totally wrong. Microsoft and all versions of IE are nine years behind web standards. It's lead developer, Chris Wilson, has stated they will follow the standards they think are important while ALL other browser makers consider the W3C the only document worth pursuing.

And that is why pages look different from browser to browser. More accurately, when one creates a page using IE, you are following an old, buggy, non-standard browser. If you expect modern browsers, such as Firefox, Opera, Safari, Camino, et al, to work like that, you are sadly mistaken.

So the solution is, if you are going to write HTML, which is a creation of the W3C and NOT Microsoft, then you should use a modern browser that follows the rules. Then you can be reasonably assured your page will work in ALL browsers; and maybe even IE. After all, even Microsoft will point you to the W3C for information about basic HTML and CSS.

In case you didn't know, IEs market share has been slowly eroding while all other browsers have been slowly increasing; perhaps due to a grass-roots movement or, perhaps, web developers like me who are sick and tired trying to get IE to do what it's supposed to do. (Firefox usage in Germany and Finland is 50%. Europe and Australia overall is about 28%.)

Keep this in mind: Chris Wilson, lead developer of IE, said himself on his blog that he realizes IE is behind in web standards and needs to catch up. If MIcrosoft thinks that, then who are we to disagree? Am I saying to not follow Microsoft/IE in all this? Darn right! You'd be foolish to do so.

[deuce789]

Hi,

Sorry you may have misunderstood me ever so slightly, i am talking about the usage of being able to provide wysiwyg through javascript (not wysiwyg itself) and the fact that the code outputted from such an editor is not w3c compliant anyway, and due to the nature of the fact that the code outputted is not going to be even remotely compliant in internet explorer and still nowhere near compliant in all other browsers (including firefox). That adding in a little attribute to fix an IE bug, that in no way affects any browsers in a bad way really isnt a big deal at all. Im sure if the author of this post was after a standards compliant solution she/he wouldnt be developing a basic dogbones rich text editor that used the default web browser behaviour for the contentEditable and execCommand. I was simply offering a 100% surefire way to fix this well known issue with ALL javascript rich text editors that are available.

It might sound like i am endorsing internet explorer, but i dont, i have been a loyal firefox user for quite a few years :-)

[drhowarddrfine]

There is no such thing as compliant markup in this browser or that. All markup is either W3C compliant or not and it never depends on the browser used. Whether that browser implements that markup correctly, which is what I think you are saying, is another issue. Right now, all versions of IE are the worst browsers on the planet.

So outputting invalid markup is the fault of the editor and not any browser or vendor or standards board.

The problem with adding a tag or attribute to fix an IE bug or quirk is that what happens if Microsoft fixes that bug in five years or more. Then that page breaks. Well, hopefully your page would change within five years.

Bert Bos, the co-creator of CSS, brought up this very subject in a recent interview.

[deuce789]

Hi,

Thx for that link, reading it now.

In regards to wysiwyg browsing and how uncompliant the code is (in all browsers, but yes, in particular IE). This is actually a browser problem, because execCommand does whatever the browser is up for doing (this does change quite abit from browser to browser, and there is no control over this aspect). Any wysiwyg editor made that uses execCommand cannot be told to output clean code directly because this function is interpreted almost entirely by the web browsers interpretation of the original microsoft integration of this into ie5, various editors have workarounds, like html cleaning functions but thats quite advanced and quite off topic from the basis of a simple wysiwyg editor. So the editor itself is not directly to blame for crappy markup.

I guess what it comes down to is the below scenario:

There is a flaw in one browser (that happens to still be the most dominant browser and therefore majority of users will be using that browser). There is only one way to fix the problem which requires putting in an attribute which right now and for the foreseeable future has no negative impact on any web browsers, even ancient web browsers (in todays terms). You have the choice to either leave the bug exposed to annoy any potential user that is using internet explorer 5, 6 or 7, or opera 7+ just because you dont want to put an attribute that may or may not break something in the future (very very unlikely that an attribute that all browsers except IE and opera completely ignore anyway, would actually decide to interpret the attribute at some point in the future). Or, put in the attribute and make everyone and everything happy? :-)