Hmm. Binds all events to `document`, which means that if you type something in a text field, it'll still trigger the event. (One of the TODOs is "Make behavior with INPUT / SELECT / TEXTAREA configurable.)
Thing is, jQuery Hotkeys (https://github.com/jeresig/jquery.hotkeys) is more versatile (since you can bind events to any element), works under a wider range of browsers, and is nearly as lightweight (if you already depend on jQuery).
Though, I do like the hipness of using "⌥" and "⌘" instead of "alt" and "meta". I might make a fork of jQuery Hotkeys just for that.
Ah, my bad. I didn't catch the line "if (tagName == 'INPUT' || tagName == 'SELECT' || tagName == 'TEXTAREA') return;", which is indeed a sensible default.
I recently had the need of using multiple hotkeys for a web application I'm building.
I tried jQuery hotkeys but I had to drop it for a number of reasons: First of all is the unbind problem (well documented on their bug-tracker), if you bind N different keys combination, the callback function for each hotkey is called N times, and that's really annoying and there are no easy workaround. Other than that, not all keys combination are supported, some keys just doesen't work, and it also bind keys per value instead of code: it's basically designed for american keyboards only, the same key value might have different key-codes for different keyboard layouts.
So I came up with a simple homemade solution that words flawlessly for my needs: http://jsfiddle.net/2Saj8/
I'm looking forward to try out keymaster.js though.
Note that because of the way the library works, you can only use the unicode equivalents on this fork—aliases like "ctrl" and "alt" will not work. (jQuery Hotkeys was written with a pretty hardcore approach to efficiency, so everything is 1:1. Keymaster uses an `indexOf` search each time a key is pressed, which has a negligible impact on performance in modern browsers.)
We don't use Keymaster, but our homebrew solution works the same way. You can solve the problem by adding an event to elements that you don't want to react that stops bubbling. Since those elements are focused when a key is pressed, the event for that element will be triggered first. Our form validation script adds this automatically. Problem solved.
Why would you store a minified version in the VCS, especially not having it in sync with the original source code? Shouldn't it be an artefact kept out of the VCS and built automatically by, for example, make and UglifyJS?
It's more convenient with a minified source layoung around somewhere. Also it's quite small:
(function(a){function j(a){d=a||"all"}function i(a,c,d){var g,h;d===undefined&&(d=c,c="all"),a=a.replace(/\s/g,""),g=a.split(","),g.forEach(function(a){h=[],a=a.split("+"),a.length>1&&(h=a.slice(0,a.length-1).map(function(a){return e[a]}),a=[a[a.length-1]]),a=a[0],a=a.length>1?f[a]:a.toUpperCase().charCodeAt(0),a in b||(b[a]=[]),b[a].push({scope:c,method:d,mods:h})})}function h(a){var b=""+a.keyCode;b in c&&(c[b]=!1)}function g(a){var e,f;f=a.target.tagName,e=""+a.keyCode;if(e in c)return c[e]=!0;if(f!="INPUT"&&f!="SELECT"&&f!="TEXTAREA"){if(!(e in b))return;b[e].forEach(function(b){(b.scope==d||b.scope=="all")&&(b.mods.length==0&&!c[16]&&!c[18]&&!c[17]&&!c[91]||b.mods.length>0&&b.mods.every(function(a){return c[a]}))&&b.method(a,b.key,b.scope)===!1&&(a.stopPropagation(),a.preventDefault())})}}var b={},c={16:!1,18:!1,17:!1,91:!1},d="all",e={shift:16,option:18,"⌥":18,alt:18,ctrl:17,control:17,command:91,"⌘":91},f={backspace:8,tab:9,enter:13,"return":13,escape:27,space:32,left:37,up:38,right:39,down:40};document.addEventListener("keydown",g,!1),document.addEventListener("keyup",h,!1),a.key=i,a.keyScope=j})(this)
By putting the source on github you're inviting people to use your code in their projects, and pick it apart. It's next to impossible to pick apart like this. In addition, a minified version is a build product, which you don't put in a VCS.
Offer the minified version as a download, that's what that feature is there for.
To a javascript mortal (i.e. someone who lacks sufficient proficiency to write or contribute to a library) this is refreshing. Looking forward to ignoring event.keyCode in my next project. Thanks for this.
I like the fact that this library has no dependencies. I suggest that the _MAP variable in keymaster.js should be equal to the specialKeys variable defined in jquery.hotkeys.js.
Why is IE < 9 support a low priority? Adding support would be pretty simple and wouldn't add much code, and IE < 9 is still used by a significant proportion of users.
Look, github is great and all, but will linking to your github repo really entice me to use your library? If its brownie points you're looking for in using github, you lost them by not providing a demo of the library and only a tiny bit of code that explains what it does.
One of things I like about github is that it's done a great job of enticing developers to write good README files. I've seen many projects that do a fine job of introducing the project, listing things like license, dependencies, etc., and showing example code of how it works. Often times it also links to a demo or screencasts. For most projects, this seems good enough -- most project web sites don't add any more value.
Thing is, jQuery Hotkeys (https://github.com/jeresig/jquery.hotkeys) is more versatile (since you can bind events to any element), works under a wider range of browsers, and is nearly as lightweight (if you already depend on jQuery).
Though, I do like the hipness of using "⌥" and "⌘" instead of "alt" and "meta". I might make a fork of jQuery Hotkeys just for that.