Re: Keyboard navigation in viewer pane - 3 scenarios.

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