Sunday, April 25, 2010

DHTML events - blast from the past

Back in 2003, I was working on JavaScript code that would function as a text editor/web page authoring tool. It worked within a browser without textarea or other input fields (text you typed appeared in the main body of the page). It was semi-functional, including pop-up right-click menus that let you paste in a few HTML tags, a Java applet to read and write files to disk, and instructions for the user to allow the applet disk access. The whole thing was pointless, as even back then there were better rich text/WYSIWYG web page editors out there, but it was a fun programming exercise. The original source for it is available here if you want to download it and toy with it. It works with IE8, but I think there was a new problem introduced with modern Firefox versions that I never got around to fixing. I also just tried it in Chrome and it just silently fails. Bummin'.

Here are a few screenshots of it in action, showing how to start with blank page, open the right-click menu to add some stuff, and testing the results:







One of the features I worked on extensively was intercepting all the meta keystrokes that power users use to dash around text editors with. For example, the Home key moved the cursor to the beginning of the line. If you pressed it in conjunction with Shift, text between the starting and ending cursor positions was highlighted. Control-Shift-Home highlighted everything to the beginning of the page, etc.

While digging through some old archived files, I found the editor and an old blog entry I wrote in April of '03 discussing intercepting keystrokes. Have a read:

I had a simplicity breakthrough today in the cross-browser work I've been doing with the in-browser HTML editor. It was an extension of the idea I used when converting Connect 4 to work with Mozilla. I'm less interested in identifying the browser up front and branching into two JavaScript trees from there, and more interested in identifying individual methods and elements that are available, and calling meta-methods.

What I was aiming for today was to prevent the F5 key from accidentally reloading the page, hence deleting everything that had been typed. Doing that cleanly in Mozilla was hard. Doing it cleanly in IE and Mozilla without causing either to throw a JavaScript error was very hard. This is the code I ended up with (simplified somewhat):
function doinit()  // called from <body onload=doinit()>
{
document.onkeypress=press;
document.onkeydown=kdown;
}
function press(e)
{
var k;
if(e){k=e.which;var ns=true;}
else{e=event;k=e.keyCode;}
if(e.keyCode==116&&ns){e.preventDefault();}
}
function kdown(e)
{
if(!e){e=event;var ie=true;}
var k=e.keyCode;
if(k==116&&ie){e.keyCode=0;return false;}
}

As it turns out, the trick was where to check for the F5. IE can kill the event from onkeydown without any complications, Netscape/Mozilla does it better during onkeypress. Deciding if "e" was automatically populated when calling press() and kdown() was a simple, short way to determine which browser.

As simple as that code looks, I had been working on it for a couple days, reading DOM references, figuring out which browser supported which things like cancleBubble, stopPropagation, whether event properties were read-only or not, etc. This will definitely become part of my standard bag-o-javascript.


Fun stuff. I originally intended for this to become part of my web page administration engine, a project that I abandoned in favor of using better tools like Blogger, Drupal, etc.

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)