Foreword
I will not write here about the evolution of the network, about the smooth transition from sites to services and web applications and to refer to other similar conclusions, with the banality of which can only be argued that their justice.
Instead, I will try to share one of my developments, sincerely hoping that this information will be really useful to someone (at least in terms of a general idea).
It's no secret that JS frameworks make the task of “hanging a hotkey on a specific button”, if not trivial, then simple enough. And even the task to simplify and automate the binding of "hot keys" to functional elements as simple as possible.
')
First of all, I will talk about the objective difficulties and limitations of the use of "hot keys".
Theory
Browser hotkeys
Yes, most of the convenient and familiar to the user "hot keys" are occupied by the browser. And this is still half the trouble, and the trouble is that they are busy in different browsers! For example, it would be wonderful to use the navigation keys ("arrows") with a modifier to navigate, for example, between pages of long lists. “With any” is good, but with what? Alt-left / Alt-right is used in FF and IE, Ctrl-left / Ctrl-right - in opera, both of these methods - in Safari for backward / forward navigation on the browser, and even if it were technically possible to block this functionality - it was would be a very, very bad idea. This is just for example, and almost all the “convenient and familiar” hot keys are already taken - otherwise, they probably would not be either familiar or (as a result) comfortable. This fact imposes significant restrictions on the use of sites, and they should be chosen very carefully.Hot keys are busy with something else
The same is true for “hot keys” employed, for example, by the operating system. For example - in the input fields the same Ctrl-left / Ctrl-right means something different, but also convenient and familiar to the user. An example with a user pressing Ctrl-left in input / textarea and receiving as a result something somewhat different from what he had in mind, suggests itself.Modifiers, generally speaking, are different.
Ctrl, Alt and Shift are present on the PC keyboard. But besides the PC there is still a lot of things ... for example, Mac. In order to correctly implement the "hot keys", it is necessary to know at least in general terms what modifiers are available on other platforms, where they are located and what they differ from ... all have such an opportunity.
Finally, I note that this is all - only difficulties, and not some insurmountable obstacles.
Practice
Idea
It is simple: we define the symbolic symbols of the keys, assign an additional class to the active elements, the name of which coincides with the symbolic designation of the key, and when you press any button, we see whether there is an active element on the page with a class that has the same name as the symbol. If there is - activate the found active element.
Implementation
The first two subtasks from my point of view are trivial and do not require detailed consideration. Let's stop on the third.
We catch pressing the button (trivially):
$(document).keydown(CheckKeyDown);
Further, it is worth somehow centrally solving the problem “do not bother the user to comfortably enter text”. I searched for a long time (but did not find it) how to determine which element currently has focus (maybe someone will tell?) To turn off the “hot keys” if the “focused” element is an input field. In the end, I decided to do without a global variable blocking hot keys:
hotkeysDisabled = false;
$('input, textarea').focus(function(){hotkeysDisabled=true;}).blur(function(){hotkeysDisabled=false});
function CheckKeyDown(e) {
if(hotkeysDisabled)
return true;
...
If anyone knows a better and more elegant way - I will be grateful for a meaningful comment.
It is time to determine the symbolic designation of the pressed key. The option “leave the number as it is” was immediately rejected - to use a symbol of the form ctrl_13 or, not to the night, be mentioned, alt_219 is extremely inconvenient. Just using String.fromCharCode () is also not enough - very often it gives such that it cannot be attributed to the class. I did not find any other standard means, therefore I made up a cumbersome and ugly construction of this kind:
function keyCodeString(e)
{
var keyCodeStrings = {
8: 'backspace',
9: 'tab',
...
222: 'quote'
}
...
s = '';
if(e.ctrlKey) s = s + 'ctrl_';
if(e.altKey) s = s + 'alt_';
return s + keyCodeStrings[e.keyCode];
}
Despite the lack of elegance of performance, this design has an undeniable advantage - it works adequately. In any case, in the laboratory.
The last step is to activate the found, if it is found. Obviously enough, but I will still describe ...
Following a link:
var keyCode = keyCodeString(e);
var selector='a.'+keyCode;
if($(selector).size() > 0)
{
location.href=$(selector).attr('href'); // your favorite load/go method
return false;
}
Activate the input field / click on the button:
$('.'+keyCode+':input').focus().click();
That's probably all.
Afterword
The full code can be found
here .
I do not pretend to fully disclose the topic, I welcome various corrections, additions and
constructive criticism. The rule applies to any part of the topic: “if you know how to do better, please tell me about it.” Thank you for attention.