Javascript insertNode workaround for IE

[methode]

Hello guys,

Yes, am new and already have a problem. I'm writing a Javascript *sniff*, something for my blog and encountered a quite serious issue: i can't find an IE workaround for the Javascript insertnode.

Basically what I want to do is to append a new span element right after a user's highlighted text. For example John Doe comes to my site, highlights a word, and right after his highlighted word a new span element appears. I know it can be done using prototype and possibly other frameworks as well, but please tell me I don't have to use a framework in order to achieve the desired effect.

Currently I have the following working code for Mozilla, Safari and Chrome:

selectionButton = document.createElement('span');
selectionButton.className = 'selection';
selectionButton.id = 'selection_id';
var range = selection.getRangeAt(0);
newRange = document.createRange();
newRange.setStart(selection.focusNode, range.endOffset);
newRange.insertNode(selectionButton);
 document.getElementById("selection_id").addEventListener("mousedown",defunct,false);

Would somebody help me please?! I don't want to rob anyone's precious time so no need for code snippet, even the right direction I should go further should do it.

Thanks in advance

[methode]

Uhh, oh. Solved.

For further reference: If you need walk around for for the W3C insertnode in IE, used with user selection:

selectionButton = document.createElement('span');
selectionButton.className = 'selection';
selectionButton.id = 'selection_id';
if(window.attachEvent) {
var sel = theSelection();
var tmp = document.createElement('div');
tmp.appendChild(selectionButton);
newRange = sel.duplicate();
newRange.setEndPoint( "StartToEnd", sel);
newRange.pasteHTML(tmp.innerHTML);
}else{
var range = selection.getRangeAt(0);
newRange = document.createRange();
newRange.setStart(selection.focusNode, range.endOffset);
newRange.insertNode(selectionButton);
}

where theSelection() is a crossbrowser function which creates the selection, object(!) in IE's case, text in all the other browsers.
if(window.attachEvent) is a weak attempt to detect whether the browser is IE. tmp is just a placeholder I used to transport the selection.

I feel kinda special :)

[methode]

Just realized that the window.attachEvent is not good for checking for Internet Explorer because Opera also uses this function :¦

Found the best solution though:

var isMSIE = /*@cc_on!@*/false;

IE uses JScript which will understand the above as: isMSIE = !false, aka TRUE. All the other browsers on the other hand can't do anything with the /*@cc_on!@*/ comment so it will be isMSIE = false.

Cool.

Anyway, I'm used with the fact that I talk with myself, sometimes I answer, too. It's just me...

[daveVk]

If it is document.createRange that is IE specific then better test would be

if (document.createRange) {

or alternatively test for function needed in non IE case.

If possible test for specific feature needed.

[methode]

Thanks for the answer Dave
Yes. That's true.
The whole script however is much longer and I need IE detection in many places, so practically I need the simplest way possible to minimize the code. I think that simpler than that comment hack is not possible and is also the most bullet-proof since I don't think there's any other browser which uses JScript dialect, thus can understand the comment.

Again, thanks for your input.

BTW, funny is that YUI has no idea what to do with the declared variable

[daveVk]

if your aim is IE detection then yes.

There are lots of versions of IE, past and future with different 'features' plus quirk modes. Much better to be not concerned with specific browsers, test if best way to do task is available then provide fallbacks, that's more bullet-proof, difference is overhead is minimal.

[methode]

Well, so you say that taking the above snippet, it would be wise to check for insertNode() availability then if not found try the IE walkaround. Right?

Thanks again for your input. Appreciated.
I think i got it.

[daveVk]

Yes should IE ever produce a decent browser (remove non standard stuff ) your script will then keep working.

By the way, welcome to the form.

[methode]

Shall I argue or just shut up? The latter is me, so... IF, by any chance IE will use Javascript dialect instead of its own JScript, AND will follow the guidelines of W3C thus using the standard DOM and functions, then the above code, presented in the second post should still work, since then IE will use the functions which I initially thought that will be used by the W3 compliant browsers. This applies (ok, almost) to the weird variable too, but only in the case if they don't give up JScript. This is unlikely since they went on their own way cos they want to be different and they do believe that their implementation of ECMAscript is way better than Javascript... yawn.

BTW, did you see yet IE8? Even though MS states that they changed the whole thing whatsoever, I don't see too much difference :¦

Thanks for the welcome

[daveVk]

Have not played with IE8 yet, believe there are at least 2 modes of compliance / compatabilty to contend with. My point is that where possible it is better to do feature detection than browser detection and yes your 2nd post uses feature detection. Two possible failure modes with 3rd post, change from JScript as you suggest or NO JScript change but else case no longer supported, odds of both probably low.

[methode]

OK, cheers. Think I got it.