I'm building a website where my users will have to enter their code quite often. Along with other data (title, tags) the user will enter anywhere from one line of code to an entire block of up to 100 lines of code.

The truly crappy part about writing code on web based forms is that when you try to do tab indentations your cursor jumps to the next input field. This makes formatting your code into a readable block nearly impossible. I know this is avoidable if you use some fancy markup techniques, but then users can't simply copy and paste their code into my textarea.

So, I wrote some javascript that hooks user's keystrokes, and if it was a tab it stops it from moving to the next input, and enters a tab character. It works absolutely perfectly, aside from one flaw. Now, when I am moving through my input form, it seems unnatural, because I can't tab to the next field.

Here's an example of exactly what is happening: http://jsfiddle.net/uu9ft/1

Obviously, I can't have both, so which is better? Tabbing for indentation in code, or tabbing to move to the next field?

8 Answers 8


I'd consider doing something to isolate the code entry field in such a way that a user doesn't become confused by the sudden "hijacking" of the tab key e.g. leave the code field until the very end of the form and have a line of text to indicate that will indent or maybe have a checkbox allowing the user to enable/disable the capturing JavaScript on the code entry field as they prefer.

I appreciate these all make more work for you, but I don't like the idea of changing the behaviour of a highly-common key in the context of navigating through a form and just relying on the user to "get it" because they might be a bit technical.

  • The checkbox idea actually just dawned on me as I was driving to work. With some good design/wording it will probably be pretty obvious/easy for users to simply click "Lock Tabs" when they want it. I can even save their preference via a cookie or in the DB so they only have to do it once.
    – jwegner
    Jun 23, 2011 at 12:14
  • Sounds grand as an approach, but I'm not 100% sure that "Lock Tabs" is the most intuitive label... ;-)
    – Sam K
    Jun 23, 2011 at 12:56
  • I think this is a good idea, and usability could be enhanced by providing keyboard shortcuts for both the 'use tab-key for indentation' checkbox and the submit-button. (And you could make that discoverable by underlining the shortcut chars, probably T and S respectively.)
    – Inca
    Jun 24, 2011 at 14:50

I see what you mean, however tabbing for the code is better in my opinion as in this case I'd much rather have the tabbing in the code than to change focus.

If I'm entering code manually then that's where the bulk of my time is invested in the controls so that's where I want the tab to be most helpful.

If I'm pasting code in then I'm not in the middle of tabbing through each control so I'd probably manually click in the next box anyway.

The only time it's annoying is when I want to move focus through all the boxes in turn but since you want people to enter code and not skip past it anyway, then I don't think it's too much of an issue. The benefits outweigh the costs in this instance.

So - unless someone can think of a way to have the cake and eat it, then use it for the code. Even if you auto-formatted the code and automagically indented the code I think once you are in a 'code' frame of mind and you just want tabs to work like they do in your favourite editor.

Note this is a special case for CODE which makes heavy use of tabs for indentation - if we were talking about text, like the very box I'm typing in now, then I'd be of a different mind


I think it depends on who your audience is. But I made a minor change to the javascript where just hitting escape will take you to the next field, which could be an option although maybe not a great one. I also made it so a shift+tab worked if you were in the text area.



Controls which trap the "Tab" key use "Ctrl+Tab" to exit the control although I don't know how common this shortcut is.

If you trap the Tab key and don't provide a keyboard shortcut to exit, you have just trapped any user who can't use a mouse in that control.

  • 1
    This being a web application, Ctrl+Tab is going to be reserved for the browser's tab switching shortcut.
    – Adam Maras
    Jun 23, 2011 at 20:54

Well, tabbing to move to the next field is better, because its common practice. you can see the below text area of stackoverflow,

enter image description here

if you look at http://jsfiddle.net/ code editors you will see here tabbing for indentation which is good practice in rich code editors.

So if you are building rich code editor i suggest you use tabbing for indentation.


For the code entry field: when entering a space that is the first character on the line or preceded by tabs, convert it to a tab.

Preserves the tab key functionality, preserves the "natural edit", and fixes over 90% of the use cases.

You might allow a workaround such as Shift-Space to enter leading spaces (not sure if this distinction is possible in javascript).


If the text control resembles a generic 'word processor' tool (or even a generic RTE-controller like TinyMCE), then I think users won't be surprised when tabbing affects the text, rather than the form's focus.

Similar to Peter, might I also suggest auto-transforming double-spaces into tabs? That is, when the user enters two spaces, the editor adds another two? AFAIK, most languages that care about indents (eg Python) are happy to interchange tabs and quadruple-spaces (though there might be exceptions to this - do check).


Perhaps you can have both; if the last action the user performed was tabbing into the code editor, don't trap the Tab key (allow it to move focus to the next field.) That way users can tab through forms, until they start editing their code (at which point the tab key lets the user indent.)

  • This would prevent a user from (easily) starting their code blocks with tabs, but I don't know whether or not that's a requirement for your UI.
    – Adam Maras
    Jun 23, 2011 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.