Cross-Browser

Once again, IE proves that it can't do anything in a standard way.

Retrieving the caret position from a text control in Firefox and Opera is a very simple job - you simply use the selectionStart and selectionEnd parameters of the control itself.

Retrieving the caret position from a text control in IE is not quite so simple. There are no parameters that give you this information, so you have to work it out for yourself. As it happens, there are a number of ways of doing this available on the internet. Unfortunatly, none of them work properly.

The "official" method of doing it according to the Microsoft Web Team in the article Yule Not Want to Miss this One (See "O Cursor, Where Art Thou—finding yourself in a text box") is just horrible:

1. Save the input field value in a temporary variable.
2. Create a TextRange object on the document.selection (assuming the input field is focused).
3. Insert a “~” character into that TextRange object (range.text = "~"). Thus, the tilde would be inserted at the caret position (which we actually want to determine).
4. Search for the “~” character in the input field value and remember the index where it was found.
   Restore the original input field value, saved at (1).
5. Return the index determined at (4) and claim it is the caret position.

The better method of doing it uses undocumented features of the Range object, and is described here by Mishoo.

This uses the Range.getBookmark() function which returns a value that can be used to get to the caret position. It worked fine. And in IE7 it stopped working. Microsoft changed the way this function worked (It's undocumented and so they can do that) and broke things that rely on it.

The third method of working out the caret position, which I have not seen mentioned anywhere on the internet and so might very well not work properly, is to use the Range.offsetLeft value. This gives you a value which represents the distance from the start of the text field that the caret is located at. In standard mode, this value is (position * 7) + 1.

This has been tested in IE5, IE5.5, IE6 and IE7 and returns the same values across all of them. It also returns the same value regardless of the zoom of the page and the location of the textbox on the screen.

As such, below is my cross-browser function to get the caret position from a given text field. It is known to work in Firefox, Opera, Netscape and (now) all versions of IE from 5.5 and up.

It seems that IE7 have managed to make things even worse in the cross-browser keyboard handling arena.

From some simple testing, it would appear that either IE7 updates the caret position before the keypress event is triggered, even though the new character isn't yet entered (and might not be entered), or (and this is more likely) the caret positions are now 1-indexed and not 0-indexed like everybody else uses.

For the vast majority of cases out there, this is not going to cause any problems at all, but if you do care about where the character being entered is meant to go in a cross-browser manner then it would appear that you are in trouble. Essentially all it means is that in IE7 your caret positions are always going to be one greater than they are in the other browsers, but it's enough of a difference to cause problems...

Edit: (See above) It appears that the problem is really that Microsoft changed the undocumented feature that I was using to get the caret position. I was using this because there is no documented way to get at the position that is worth considering.

Different browsers handle events in different ways. Unfortunatly, this means that the same function will receive it's data in different ways on different browsers. From the major three:

• Firefox. Event object is passed as parameter to the callback function
• Opera. Event object is passed as a parameter to the callback function. Some members of event object have different names
• Internet Explorer. No parameters passed to callback function. Event object exists as a global variable(!) instead. Some members of event object have different names.

Whilst Internet Explorer does use a global variable to store the event object, this is actually less of a problem since the javascript engine is single-threaded. It shouldn't be possible to have two event handlers for two different events using the same event object. This could change in IE7 or later however, at which time things will likely all stop working in a horrible manner.

This snippit can be called, being passed the event parameter from the event handler, and will return an event object in a standardised way. Note that this is nowhere near finished, and still has a lot of work needed to cover everything. In specific, keyboard handling is very rudimentary (see below) and mouse handling is non-existant.

Keyboard handling in Javascript events gives a whole new meaning to "impossible". It turns out that there is simply no reliable way to do this and still have your code work across the board.

The main problem here turns out to be Opera. Opera, in their ultimate wisdom, have decided that in the keypress event they will give you the Keyboard code for function keys, and Character code for all other keys. The problem is that they give you this code in the same variable in the event object.

The problem comes from the fact that the keyboard code and the character code can, and often do, overlap each other. For example, the character code for the period character is 46. It just so happens that the keyboard code for the delete key is also 46. Having compared the event object that is passed into the keypress event when the period and the delete key are pressed, the event objects are identical. There is not a single way to tell the difference between those two keys in that event!

As it happens, the reason I was trying to do this was to have a text field that only allows certain keys to be pressed. Period wasn't one of the keys, but I did want all the function keys to work (arrows, delete, home, end, etc). Another "feature" of Opera is that these keys can not be cancelled. As such, if I think it might be a period I can try and cancel it, and if it's a period it's cancelled and if it's a delete then it's not.

This code is a simple Javascript function that works in most modern browsers to return a document element given the name of the element. It requires that both the name and id attribute of the control be set to the same value, and this value is what is used to look up the element.

One of the good things about Javascript is that it runs on any web browser that has support for it. This means that you can write your code and know that anyone with a recent enough browser can run it and benefit from it.

One of the bad things about Javascript is that it runs on any web browser, and that the people who write web browsers rarely do things the same as each other. This means that your code that works perfectly on Firefox will likely totally fail to run at all on Internet Explorer, or Opera, or whichever browser you want to use.

Because of this, it becomes very difficult to write powerful Javascript applications that are going to work for even the majority of users, and (almost) impossible to write them so that they will work for all users.