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.document.queryCommandEnabled('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="navoCHatEditor" width="100%" height="100" onfocus="setKeypressHandler(window.frames.navoCHat Editor, keyPressHandler)" ></IFRAME>
[/HTML]
//js part

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 setKeypressHandler (windowOrFrame, keyHandler) {
  var doc = windowOrFrame.document;
  if (doc) {
    if (doc.addEventListener) {
      doc.addEventListener(
        'keypress',
        keyHandler,
        false
      );
    }
    else if (doc.attachEvent) { 
      doc.attachEvent(
        'onkeypress',
        function () { keyHandler(windowOrFrame.event); }
      );
    }
    else {
      doc.onkeypress = keyHandler;
    }
  }
}
 
 
 
 
function initEditMode (frame) {
  if (frame.document) {
        frame.document.designMode = 'on';
      }
}
 
window.onload = function (evt) {
  var editFrame = window.frames.navoCHatEditor;
  setKeypressHandler(editFrame, keyPressHandler);
  initEditMode(navoCHatEditor);
};
 
function RunCom(what) {
 
 
//**************************************
 
    if (navoCHatEditor.document.queryCommandEnabled(what) == true)
    {
        navoCHatEditor.focus();
        navoCHatEditor.document.execCommand(what,false,"");    
 
    }    
    else
    {
        alert('command' + what + ' not enabled')
    }    
 
}
 
function ForeColor(col)
{
    navoCHatEditor.document.execCommand("ForeColor",0,col);
    navoCHatEditor.focus();
}
 
/////

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 "unselectable" attribute.

[acoder]

There is no such thing as an "unselectable" 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? :-)

[drhowarddrfine]

In regards to wysiwyg browsing and how uncompliant the code is

Not to nitpick but, again, the browser has nothing to do with whether code is compliant. The code is compliant or not and the browser has nothing to do with it.

This is actually a browser problem, because execCommand does whatever the browser is up for doing

You can see here that Firefox is more up to "doing" than IE is.

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... So the editor itself is not directly to blame for crappy markup.

One of a bazillion reasons not to use these automatic code generators.

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).

A list of flaws in browsers.

put in the attribute and make everyone and everything happy?

Is there a workaround that can be used instead? In html/css, there are so many things IE does wrong, or not at all, but rather than catering to it with invalid markup, we can introduce 'hacks' and, now, "conditional statements" without tripping up modern browsers. Some, not me, would use proprietary elements because there is just no other way around the problem but I have never found that case myself.

In the new book "Transcending CSS", written and edited by some of the top web designers, they advocate using all the current working tools available in html/css/javascript, whether they work in all browsers or not (specifically mentioning IE). When IE fails to perform, then so be it, excepting functionality, of course, but all other browsers benefit from the modern feature/technique.

And now I forgot what point I was trying to make with that paragraph. Must get second cup of coffee.

[deuce789]

I understand where you are coming from dont get me wrong, but how compliant the outputted code from a wysiwyg editor is directly related to what browser the user is using and although internet explorer is the worst, all of the other browsers that support wysiwyg may be better with their output code, they are still far from perfect as far as following w3c standards 100%. God help us if a simple attribute can break a whole web page in the future.

The way ALL wysiwyg editors using the browser behaviours need to use hacks in order to work properly in all web browsers, if your suggesting this can be done with all standard code id like to see :). Ive been involved in the development of two wysiwyg editors and have provided several bug fixes to other wysiwyg vendors and can say with certainty that it is impossible to make an editor that uses the default browser commands for wysiwyg editing be 100% compliant in everything yet still retain full functionality in all browsers, there are too many unknown variables.

This topic has gone way off topic anyway... The point is the author never made any mention to any of the nitty gritty and quite frankly if he/she cared, they wouldnt be trying to work out a solution using execCommand and the code they provided would have been W3C compliant (which it was not and was obvisouly made with IE in mind [telltale signs, caps tag names, javascript mixed with html, etc etc]). They wanted a fix, i provided a fix, all you have done is tried to argue a point (which is a reasonable point, but in this case a mute point). To bother about a simple attribute when the editor itself will output much worse "w3c standard" html (yes even firefox) seems totally irrelevant, and considering the fact its been 10+ years since it was introduced in ie4, and to this date, has never caused any issues in any web browsers at all, it makes it even less irrelevant. Sometimes you have to draw a line, if your bothered about a simple "invalid attribute" what about dealing with all the unclosed tags, and deprecated tags that ALL of the browsers incorporate into their basic default interpretation of execCommand, for a simple WYSIWYG it seems far out of scope of the authors original post and request for help.

//End Rant

[drhowarddrfine]

I can't speak for editor or even execCommand. I can only say that editors are going to have to learn to follow the rules just like we web developers do. And anyone who can't get a web site to be 100% valid doesn't know what they are doing or isn't trying. If MSN.com can be 100% valid, so can everyone else. (And, yes, all my web sites, from static through e-commerce, are, too).

[acoder]

You can see here that Firefox is more up to "doing" than IE is.

Opera is surprisingly bad (almost as bad as IE), but all browsers need to improve. That will probably come over time.

[acoder]

I can't speak for editor or even execCommand. I can only say that editors are going to have to learn to follow the rules just like we web developers do.

Unfortunately, deuce789 is correct when it comes to the output produced by browsers. See the test link.

[acoder]

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.

I haven't really worked with execCommand and WYSIWYG much. Do you know if this attribute can be set using JavaScript?

[deuce789]

Yes, it can (with setAttribute) anyway :-)

[acoder]

Yes, it can (with setAttribute) anyway :-)

Thanks! Maybe that would be better to keep everyone happy.

[drhowarddrfine]

I have a feeling deuce and I were not quite talking about the same thing. Since I'm more of the html/css guy, I spoke more of that type of validation than anything to do with javascript.