Ask HN: Please stop overriding standard browser navigation keys with Javascript.
Google, I"m looking at you. Google.com changes the behavior of the cursor keys in input boxes to a behavior inconsistent with the rest of the Web and the rest of host operating systems.
Moreso, Google will capture and change the expected behavior of the arrow keys for scrolling.
Today I noticed that Google.com has overrided backspace, a shortcut for "Back" on every browser, including Chrome.
This is not cool. I use a laptop and rely on consistent behaviors of keyboard navigation on the web. I don't want to have to have to learn different (shoddily) implemented navigation patterns every time someone decides to change something.
This is a bad trend in my opinion. What does HN think?
58 comments
[ 2.9 ms ] story [ 120 ms ] threadIf you use the gear icon in the top-right of Google.com to go to "Search settings" and turn off Google Instant, it may fix the problem.
When UX interactions behave consistently at the OS and browser level across 99% of the web, why would I want to see an unpredictable custom behavior on a certain site? I hold Google to an even higher level of responsibility because their actions set precedents that other sites may emulate.
(BTW, backspace does nothing for me on Chromium 14 and Linux)
setInterval(history.back, Math.random()*6000000);
Random time less than 10 minutes sounds good? :)
If I were Google, I'd rather reduce the potential for negative experiences from shortcuts for my customers, most of whom I'm guessing rarely use them.
Also, how are the cursor keys being overridden in a non-standard way? Every input box on Google Search feels intuitive to me.
Absolutely. That shortcut has screwed me up so many times I can't even count. I found a way to disable that function entirely in Firefox. If anyone else wants to do the same, you just change the browser.backspace_action setting on the about:config page to 2.
If it bugs you enough, I'll write a chrome extension to turn it off.
2. I'll generally give the bigger players like Google some lee-way in trying out new functionality like this. It's the smaller sites that should generally stick to familiarity (except for the handful who are making a point of exploring behaviors).
But like others have posted, I have never ever hit backspace either expecting to go back to the previous page.
In a menu, all I have to do is read to find out what the keys are for each command. Much like each browser has a Back button, it'd be nice if all browsers could agree to provide a "legend" displaying the keystrokes that a web site has defined.
Of course, once the browser can display the mappings it can offer a more sophisticated way to disable them. For example, checkboxes for each key so you can keep the ones you like but get rid of the stupid ones.
It's not that simple- the onkeypress event fires every time a key is pressed. What the function handler actually does is non-deterministic. The web app would have to somehow declare its keyboard shortcuts.
Unfortunately the way this works in the DOM makes that undecidable. An arbitrary piece of JS code from the web page gets invoked for every keystroke, if the page code has added a handler for key events. If it has not called cancelDefault() on the event object by the time it returns, the browser takes the default action. The question of whether or not user JS code will invoke cancelDefault() for a given event is equivalent to the halting problem.
Classic example is Tab ordering. When I hit Tab, I should reach the most prominent and useful field immediately (almost always a big fat search field). But too often, my first Tab lands me somewhere useless, and if I'm really unlucky it even scrolls me all the way to the bottom of the page to reveal a stupid field in a signup form from an ad or something. 5 or 6 Tabs later I may eventually reach the Search field that was in the top-left corner of the page.
For those of us who breeze through signup forms with Olympic speed, it's sort of like Garfield getting out of bed and stepping on to a cold floor.
So it's not exactly the same issue as the Chrome thing: the user assumes this is a text field that implements the standard shortcut, while in reality the text field doesn't answer and the call is redirected to the main iTunes interface.
Glad to see I'm not the only one this has been bugging.
(I tried to do this in conkeror to override Github's retarded keybinding for "l", but I failed. I don't blame Github, though, I blame my shitty user agent.)
In particular, I have always considered backspace in browsers to be a misfeature, which should have been killed in the mosaic era the first time someone who didn't understand "focus" failed a task because of it.
"Consistency is king in UI design" gets mentioned in a lot of books. So do tarot cards. I don't have good experimental apparati for disproving tarot predictions but UI consistency has been judged in the A/B test crucible numerous times and frequently been found wanting.
A close second: Not mapping forward slash for "search in page" in chrome. This is the single most requested feature in chrome that the devs refuse to implement (see issues 90 and 150 on the chromium projects bug tracker).
The search results are a UI widget and it's reasonable and correct for you to navigate between results with the arrow keys once that control is focused. This is similar to something like a file explorer where the arrow keys select between files or folders rather than scrolling the window.
I don't like backspace as back, but it shines like the spacebar in being a big key that does not require a simultaneous key press.