Re: Keyboard navigation in viewer pane - 3 scenarios.

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 Friday, 13 July 2007 23:31:08 UTC