- From: Chris Blouch <cblouch@aol.com>
- Date: Tue, 17 Jul 2007 11:46:12 -0400
- To: Earl.Johnson@Sun.COM
- CC: wai-xtech@w3.org, Tom Wlodkowski <Thomas.Wlodkowski@corp.aol.com>, Becky Gibson <Becky_Gibson@notesdev.ibm.com>
In my testing I attached by event handler to the document rather than to a specific DOM object. Maybe that makes a difference. In general I registered _keyget to hande all "keydown" events on the "document" object and then went from there. I attempted to stop event bubbling in several ways but in IE, control-p still brought up the print dialogue after executing my JS function. Here is part of my function: _keyget:function(event){ //In IE look in window.event on FF look in passed-in var e=event||window.event; var key=e.keyCode||e.which; Do stuff with the key //Stop propogation the IE way e.cancelBubble=true; e.returnValue=false; //Stop propogation the standards way if(e.stopPropagation){ e.stopPropagation(); e.preventDefault(); } return false; } I registered the event this way: ae(document,"keydown",_keyget); and the ae function looks like this //Add function fn to be called when object o fires event et //Handles both the standard addEventListner and IE attachEvent ways to do this. //Works around a pile of IE bugs/quirks with attachEvent //Using m for the method works around a Safari quirk ae:function(o,et,fn){ var m="addEventListener",x,t=et+fn; if(o[m])o[m](et,fn,false); else if((x=o.attachEvent)){ o['e'+t]=fn; o[t]=function(){o['e'+t](window.event)} x('on'+et,o[t]); } } Hope this helps. CB Earl.Johnson@Sun.COM wrote: > > Hi Chris; > > My understanding, from a researcch only stance, is all keysequences > can be repurposed in javascript so the browser never sees the > keypress. Here's a code example I found for how this might be done: > > ----------- > > function repurposeKeyPress(e) > { > if (!e) e = window.event; > if (e && e.keyCode == 40) > { > // handle Down key > // return false; here to cancel the event > } > } > > <textarea onkeypress="return repurposeKeyPress(event);">... > </textarea> > > --------- > > More examples of repurposing that works in Firefox at least, can be > checked out at the following link. It's biggest drawback tho, from an > IE perspective, is it is XHTML. > > I assumed a re-purposing function/method similar to this would work > for all since jabvascript, being in the page content, always sees the > keystrokes before the browsxer even. Your post has me unswure about my > assumption now tho - would something like the above function coupled > with the appropriate page m/u on the element overcome the example > issues you cite below or have you already tried something similar that > fails? > > Thanks Earl > > > > Chris Blouch wrote: > >> I'm not sure that the "same" keystrokes can be used. The main >> limitation is that the OS, browser and screen readers have already >> commandeered many of them for their own purposes. For example, in my >> testing I could make control-P do something on my web page but in IE >> is still causes the print dialog to pop up. On Firefox though I can >> actually take over control-P and make it do only my function. Alt-P >> is free so in my example I could use that instead of control-P to >> implement some behavior. Similar substitutions may be made for >> defined alt combinations. For example alt-t in IE brings up the Tools >> menu but control-T seems to be clear. So if we want an IE friendly >> solution we'll have to steer clear of any keyboard combinations which >> are already in use which limits how close our web widgets can emulate >> keyboard controls of OS-native widgets. Best we can probably do is >> "similar" key combinations. >> >> Chris Blouch >> >> Earl.Johnson@Sun.COM wrote: >> >>> >>> Hi Tom; >>> >>> I think the agreement coming out of our last meeting was basically >>> "widgets that have a desktop component counterpart [e.g. tabbed >>> pane] should implement the same keystrokes as their desktop brethren." >>> >>> To simplify things for our purposes [i.e. disregard flash player, >>> etc], we could say there are 3 possibilities for page content: >>> 1. Contains only dojo javascript widgets >>> 2. Contains dojo javascript widgets and html4 elements outside >>> the widgets [e.g. Netflix?] >>> 3. Old Bessie: all html4 elements >>> >>> I don't recall the outcome of discussions when it came to scenarios >>> 2&3. It sounded like this topic has been discussed multiple times >>> before I joined in but I'd appreciate making sure I understand what >>> will happen when someone hits a scenario 2&3 page. Would it be >>> possible to spend a little more time on this discussion in >>> tommorrow's styleguide meeting [if there is one]? >>> >>> Thanks, Earl >>> >>> > >
Received on Tuesday, 17 July 2007 15:47:36 UTC