Tabs in textboxes

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

http://jsfiddle.net/uu9ft/10/

Answer 4

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.

Answer 5

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

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.

Answer 6

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).

Answer 7

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).

Answer 8

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.)