Let’s say you’re viewing different pages in your browser, and in the midst of your browsing you decide to visit Google’s home page. So you see this:
Notice the blinking cursor. This means the cursor has been automatically focused into the search field, either via JavaScript or using HTML5’s autofocus attribute.
If you happen to change your mind about typing a search, and you want to go “back”, you can do one of two things. You can (1) use the back button in the browser, or (2) you can use the backspace key on your keyboard (on a Mac it’s the “delete” key).
If you decide to use the keyboard method, your experience will be broken, because when you’re inside a text field, the “backspace” key means “delete text”. So the browser will not go back in its history, as you would expect. And naturally, shift-backspace (which is forward in history) would likewise fail.
Personally, I’ve always found this annoying, and I’m glad a person with a disability mentioned it, because I decided to try to create a simple fix for this problem using JavaScript:
See the Pen Fixing Google’s autofocus-no-backspace problem by Louis Lazaris (@impressivewebs) on CodePen.
The script does the following:
- Look for keystrokes in the text field
- Make sure the field is empty after the keystroke
- Check if the key pressed is the backspace (8) or delete key (46)
- If it is, check if the shift key is being pushed
- Go back or forward in the browser history
The script seems to work in every browser except IE8. And oddly, although I’ve added the ability to use shift-backspace (shift-delete on Mac) to go forward in browser history, IE10 doesn’t seem to recognize this shortcut like previous versions of IE seemed to do (if I remember correctly).
Flaws
Besides the IE flaws just mentioned, one of the flaws in this script is the fact that the keystroke that it looks for can be either backspace or delete (which ensures it works on PC and Mac). So the result of this is that if you push “delete” on a PC keyboard (which is a different button than “backspace”), it too will cause the history-back functionality to occur. But I don’t think that’s such a big deal, really.
Finally, the other flaw in this is that if someone deletes what they were typing in the search box and they hit backspace/delete one too many times, it will cause the history-back fuctionality to trigger. I started to try to figure out how to cancel the event once the user begins to type actual visible text, but couldn’t figure out how to do it. Maybe someone can fork the CodePen and add that to it.
The demo seems to work fine on CodePen, but because because CodePen embeds the full-page view in an iframe, it seems a little unnatural, so I’ve provided a bare-bones demo to test instead, using the button below.
And obviously, if you click the demo button below, stay in the same tab, so you’ll have something to go “back” to.
This is a great idea, but I think it would be even better if you include include also Cmd+left and cmd+right for back and forward browser history in Mac (I tried this shortcut successfully in Firefox, Chrome, Safari and Opera). The equivalent in Windows is, if I remember correctly, alt+left and alt+right.
The “hit backspace/delete one too many times” issue could be dealt with by adding an “isDirty” attribute to the text field, which is set to “true” when the text field has contained text. Like in this pen: http://codepen.io/anon/pen/kLhux
The user might also hold down backspace, particularly for lots of text, to clear an entire field. Too many backspaces would undoubtedly be an issue there too.
Your version works well to avoid this, but I think it might need an additional tweak – for instance if the field is pre-populated (by the value attribute or if the browser pre-fills/retains a value) the dirty flag is not set and the backspace ‘fault’ still exists.
Incidentally, the Alt+Left arrow combination for Windows (Chrome) doesn’t appear to work within the Codepen editors. Perhaps they are making efforts to intercept it?
It’s true that my version doesn’t support pre-populated text fields, but the primary version doesn’t support that scenario either. You could think of many more requirements that aren’t supported in both versions. I hereby invite you to create a nice JS plug-in with the specs you’ve added ;-)
This is definitely a slippery slope. Which of these two is more of a jolt:
1.
Expectation: Press backspace and go back in history
Outcome: Nothing happens because the focus is on an input or textarea
2.
Expectation: Press backspace in an input or textarea and nothing happens
Outcome: You go back in history
I think #2 is more alarming. In your Flaws section, you said that maybe you could remove this functionality once the user has typed something. That would help a little, but I still think #2 is way worse than #1.
In my opinion, if this is a problem on your site, don’t use autofocus.
I agree, I think this medicine is worse than the disease.
I agree to some extent. For example, I wouldn’t use it on a contact form that autofocuses. Of course, I don’t think I’d ever autofocus on a contact form anyhow.
But I definitely think Google should use it, and so should other sites that autofocus and that only have one purpose on their page (i.e. a simple field to fill out). I think the odds of someone hitting backspace too often is not that likely.
But hey, it’s just a fun experiment. Whatevs. :)
Good points and yes, definitely a good experiment! FYI, I just noticed that Facebook autofocuses on their login form if you are logged out. In my case, since my email is auto-populated, we run into the issue that Sven alluded to above where we can’t determine whether the user meant to go back in history or delete text, and we have no choice but to assume they want to delete text.
If the email is auto-populated by the browser, and the email field is the one that’s autofocused, then hitting backspace will not trigger history with my script. This script detects first if the field is empty, and will only trigger backspace if it’s empty.
Yeah I have to agree with Jared. Especially when there are dedicated forward and backwards keys on all Mac browsers at least. Cmd + [ to go back ALWAYS, regardless of input field or not. I think it’s a reasonable expectation that mouseless users should memorize some shortcuts even if they’re more ambiguous than delete.
Considering the functionality of having the backspace key performing the browser back action is terrible to begin with, this script is equally awful. A better script to have would be one that prevents the backspace key from ever performing back.
I couldn’t disagree more. Having that quick keyboard option is very useful, especially for users that depend on the keyboard a lot. It’s much quicker to do that than to use the mouse to find the “back” button.
I agree entirely with Kyle (and Luke). There is already a keyboard shortcut for going back a page (Luke, on Windows it’s Alt-left_arrow).
Having the backspace key sometimes perform its normal function (backspacing to correct an error) and sometimes performing another (go to the previous page, losing all data you entered in any forms on this page) is a horrible experience.
You wouldn’t lose any data. This type of thing would never be used on a page with a full form to fill out. Only on a single-form page like Google’s home page. Once the user starts typing, the backspace key does exactly what it’s supposed to do: erase text backwards. So there’s no data lost at all.
It’s way too easy for the text field(s) to lose the mouse focus, especially on a laptop, in my experience, and then the backspace does something I do not expect nor want. (Just as infuriating is the stupid “document back” and “document forward” keys that many laptops have — it’s way too easy to accidentally hit the “document back” key when trying to hit the up arrow while editing an email or an essay on a test, for example.)
I realise that many people like the function of the backspace key, and it has been in IE for many years. Many people also do not like it that way, so why not make it configurable? All other major browsers offer a way to turn that “feature” off.
Hi Louis,
Looks great, It will be useful, will not give big influence but useful to save time. Sometimes we irritate, when we are in hurry to find something, and things not happen in our favor. Will use this tip.
Thanks. :)
One could check user agent to determine what os user in on?
Sorry, but this is a terrible idea. The whole concept of the backspace key being tied to the browser back button is a horrible feature and it should never have been that way at all. There are all sorts of other keyboard shortcuts that could be used, and I would support a browser option to map custom keyboard shortcuts as a user option, but the default behavior for a backspace button should never leave the current page.
The problem is that, due to the nature of it being necessary to use the backspace key for typing, it will inevitably lead to data loss or break web applications when someone hits backspace when a text field isn’t focused and they aren’t meaning to “go back”. As I mentioned before, there are plenty of other keyboard shortcuts that could be used, and if someone was dead set on using the backspace key that way then there could be options in particular browsers to allow it as a user option, but having that as default behavior is pretty crazy, and trying to force that behavior when even focused on a text field with scripts is even more problematic.
It would be far better to write some browser plugins that could be installed for users (with disabilities or not) that prefer to have the backspace key do all manner of different things to their hearts content. Sorry for the rant, but a lot of people coming to this page are probably searching for reasons why the backspace key has anything to do with navigation and why browser developers don’t just move past this bad design decision once and for all.
I understand your point.
The only problem is that you seem to be ignoring the fact that the backspace key used as back button is a reality, and people are used to it. This script is attempting to re-enable that in situations where it’s expected.
You’re probably right that it was a terrible design decision in the first place, but that doesn’t change the fact that many users are accustomed to it.
The backspace key has acted as browser history navigation short-cut since time immemorial. The fact that you, me or others find it illogical and irritating is irrelevant. There are people out there with disabilities who struggle to use a mouse (or other such device) and rely on de-facto standard (i.e long-time) keyboard short-cuts, of which this is just one.
Now if, say like Google, you autofocus on load using client-side code because it is a perceived convenience to the user (in Google’s case though it is about revenue generation though, not convenience) then you as the developer are already changing the default behaviour of the browser. The default behaviour of browsers is to load a page and display it – Nothing more. Nothing less. Anything beyond, such as changing focus on the client-side, is a change of default behaviour.
So, having changed the default behaviour users start to expect certain things to happen. i.e. Google auto-focuses. You expect backspace to clear textbox content. Again, this involves using client-side code and trapping the appropriate key code. Having already changed a brower’s default behaviour, to further enforce this, and to make a consistent experience for the user, it then becomes necessary to detect focus when the backspace is pressed. Is the focus on the text box? If not re-focus before executing the backspace keypress. Hey presto. Job done. Fluent and consistent user-experience. BUT… the default behaviour has been changed.
Across sites this creates an inconsistent user-experience, but that inconsistency is is created by sites such as Google that change default browser behaviour.
Whilst it makes perfect sense to change the default behaviour on the client for a consistent user-experience it then, as already mentioned, breaks consistency across sites.
Personally I know several disable people that absolutely hate such changes to default behaviour as it makes their life just that little bit more awkward and for whom I developed a small browser extension to disable such behaviour changes.
There’s always two sides to a debate. Personally, although I find backspace as a history navigation somewhat awkward (to be polite about it) I think it’s best to leave de-facto default behaviour ‘as is’, for those who are less able and continue to find it a convenience. If it makes life a little more awkward for some of us then I’d say that’s a small price to pay for the convenience of those less able-bodied individuals out there.
Couple comments:
1. Autofocusing fields is dumb.
2. Using the backspace key to go back a page is dumb.
Solution is don’t autofocus fields, and users can use the standard shortcuts for moving around pages. The backspace / delete key is for text entry not browser navigation.
That is the most awesome trick to keep your visitor on your website and make your website more engaging.
That’s being said, Can you share such awesome tricks to keep visitors more engaged.
By the way you can check out this article on the most interesting hacks. http://www.webdesignerpad.com/2014/04/the-most-interesting-htmljsdomcss-hacks.html
Indeed we can make these tricks to users to stay focused on our website so that our bounce rate will remain idle. Thanks for posting dear. Keep sharing. From – Ashray
i also like to use back button to go back
According to me this is a not a good idea. It’s like that medicine which is worst than disease.
This is a terrible idea.
This is not a good idea at all.
Agree with others, not sure if it’s something you’d like to implement.