Keypress: A Javascript library for capturing input
dmauro.github.io
dmauro.github.io
The reason is because what this usually looks like "oh nice I can define shortcuts people can press". What it actually means is: "Ohcrap, that shortcut only works for US-US 104 keyboard layouts, and about 80% of people can't press that shortcut".
For example: suppose you want a shortcut for shift+/, which is for the US keyboard under the small right finger. But that shortcut can't be defined for SG (swiss-german) because there the / is on the numeric bar where 7 is. So if you assume (for whatever reason) that left+right small finger is a convenient shortcut, and left small finger + right index finger top isn't, then you're totally screwed. Instead, to reach the right small finger low on swiss german, you'd have to define shift + "-". Except that if you define that, it'll be one of the most uncomfortable keyboard shortcuts imaginable for US users, which find - on the numeric row top --> bottom left small finger + top right small finger = ugh.
The truth is that you cannot do reasonable shortcut definition the way that everybody would like to with JS... yet.
But wait, can't you like, define some reasonable presets and let people choose their own? The answer is no, because you don't have a reliable way to translate a keydown/keyup to a unicode char, and the unicode char is related to the modifier keys, not the key cap, so though you can do that shortcut definition, you can't show to the user what that shortcut definition actually is, because it'd be either undefined or completely wrong.
I've written at length about this here: http://codeflow.org/entries/2013/jan/30/keyboard-events-in-j...
But couldn't you let the user write the shortcut in a text field, capture the keycodes from the keydown/keyup events and the char from the text field?
Edit: This obviously doesn't work for shortcuts that do not produce any text, such as F-keys. But couldn't you at least get normal keys right most of the time?
But if you're going this far, you're probably significantly better off just letting people remap their shortcuts if it doesn't match what 95% of your users are using. The ones that care will love you for it, the ones that don't probably wouldn't have used it or been interested in 20-questions anyway.
couldn't agree more (learned the hard way), doing shortcuts with js is like translating your app into 50 different languages but only for half the keys - it creates a jumbled mess - best practice here is to never even do it.
JavaScript code traditionally uses PascalCaseNames for constructors and camelCaseNames for variables, properties, and methods. You do see UPPERCASE_NAMES_WITH_UNDERSCORES used sometimes for "constants", but that's about it.
Of course, names_with_underscores work just as well as any other names, and some people use them in their own JavaScript code, but I think libraries should follow the traditional native conventions of their language.
It would be like releasing a Ruby library that used camelCaseNames for its method names. It would work, but many Ruby developers would feel that those names were a bit out of place in a language where method names customarily use underscores.
Mentioning it here basically just as a reminder for other library developers: "When in Rome..."
Especially if you program in multiple language it can be jarring to switch styles for each language.
I think that flexibility of style has been getting less and less favor recently : a lot of languages are starting to "force" some elements (such as indentation) , and go has done the most intelligent thing ever and ships with a formatter so that there's only 1 "right" way to write things.
Formatting issues is the source of so much bike-shedding, despite that it really shouldn't be much of a productivity sink in 99.9% of situations.
Take C# and the BCL. C# is a language but you'd be hard pressed to avoid using the BCL in any meaningful C# program.
String.Format("Hello {0}", stringVariable);
All (nearly all?) the function names in the BCL are UpperCamelCase, and a lot of C# code follows that as a convention.Repeat for class names, interfaces prefixed with I, public properties etc.
But if I'm writing code for someone else I try to follow the language's conventions if possible. Especially if it's a library that will be combined with other libraries and application code that does follow native conventions.
After all, it's also jarring to write code in one language that has to use multiple styles because it integrates libraries that weren't consistent with the common language conventions.
Cross-browser idiosyncrasies are finally improving...except for webapp key bindings. Alt-F is taken in IE, Ctrl-whatever is taken in other UAs. Or an extension like (the awesome) vimium conflicts with some key bindings, so you have to disable it all together.
To the point where Asana uses tab as their short cut key. Tab! Wtf! "tab-p" for project. Bizarre!
But I guess I can't blame them, as I wouldn't be surprised if it's the only shortcut modifier that wasn't taken yet across all UAs.
I admittedly have no solutions to propose, so am just ranting about an understandably hard problem...but it would be nice if someone came along and fixed this. Please. :-)
I don't personally do it, but its not unheard of ------
Not that I'm saying you're wrong, I really don't know if normal driverless keyboard input is capable of this. I certainly hope so. I just see essentially all 10-key rollover (or more) keyboards using PS/2 and citing that it doesn't work through USB.
On a similar topic, does anybody have any pointers for implementing keystroke-by-keystroke character replacement in an INPUT box that doesn't suck? I'd like users to be able to enter "townhall" but have the input value be "TOWNHALL" and there doesn't seem to be a simple way to do this that doesn't fail when the user uses the arrow key or wants to insert more than one character in the middle of an input box.
text-transform: uppercase;
It's simple, the user experience remains natural, and there are no JavaScript dependencies. For the transmission phase, simply munge the actual entered content (which will not be all uppercase unless the user enters it as such) during the submit event. Of course you'll want to validate input on the server side as well.Edit: clarity.
Otherwise features from the browser like "incremental search" in firefox will get priority over the key captures in your app. In fact both your key capture and the incremental search will trigger which is very frustrating as the page starts scrolling to the first match of the letter you just typed.
But be very careful while doing this. Only do it for for your own hotkeys and make sure they are not used for other hotkeys in most common browsers! If you always swallow the keypress, normal hotkeys like ctrl+t for new tab will stop working for the user also.
For instance you want to make a game using WSAD keys, well in a french keyboard it's ZSQD... Also in a French keyboard, there some keys which trigger the same keycode so you cannot differenciate them! (I think it was the comma with something else)
If you want to make a software like Blender on the web which have a lot of key shortcuts you are a bit screwed!
document.body.addEventListener('keydown', function(e) {
if (e.target.tagName !== 'INPUT') doKeyBindings();
}, false);At least give data enterers feedback, WPM, errors. Elderly can do data entry while on a walk to the park, and afford their peppermints.
> Open page
> Don't touch anything
> Type
this is a test
> Now you've moved down three times.It doesn't work unless you interact with elements on the page first, in which case the library catches space.
Hence my instruction not to touch anything on the page.