Do you think that giving TAB formatting functionality will improve UX?

I've seen people complain about not been able to use TAB to format code in SE. There are many fixes such as:

  • format code in a text editor before hand.
  • use CTRL + K.
  • install a user-script, if you're into that kind of thing.
  • suck it up and use SPACE x 4.

The request to implement tab formatting functionality has been denied by SE, and refuted on the claim that this would damage TAB's native functionality in the browser.

As a developer who focuses on UX, I think there are solutions that avoid damaging Tab's native functionality for disabled users.

I believe that when editing code, TAB is expected by most users to create a tab, not jump to the next element in the page, and for convenience, a method of adding quick tabs can and should exist.

  • 3
    Tab order. Moving from element to element, as is native in the browser? What you are asking breaks that.
    – Oded
    Jun 24, 2014 at 19:38
  • 10
    Nobody expects the native functionality when formatting code. I just noticed how nice it is in JSFiddle that TAB does what I expect it to do. @Oded
    – J.Todd
    Jun 24, 2014 at 19:39
  • 1
    possible duplicate of Make TAB work on the editor Jun 24, 2014 at 19:43
  • Why don't you ask jsfiddle to let us upload pictures in their editor? Each site and its own editor. :) Jun 24, 2014 at 19:44
  • 4
    @ShadowWizard you're one of those people who avoid solutions by arguing with false logic.. So is the guy who answered the question you linked.
    – J.Todd
    Jun 24, 2014 at 19:45
  • I'm using balpha's user script, totally worth it.
    – brasofilo
    Jun 24, 2014 at 19:51
  • 1
    Not a dupe but now it's "primarily opinion-based" so still, would personally close vote it. Anyway I personally never treated SE's editor as IDE, just ordinary text box allowing little formatting. Code should be indented before posting and I find it totally sensible. JSFiddle is meant to write code from scratch, so IDE-like behavior is expected and important. Users should not write code from scratch in Stack Overflow, but rather post existing code, which is expected to already be formatted/indented. Jun 24, 2014 at 20:05
  • 6
    @ShadowWizard Users should not write code from scratch in Stack Overflow I have to strongly disagree. This is a matter of user experience and the fact is: Users need to write code examples sometimes, and the editor is open in front of them, whilst opening a new blank document in an IDE takes time.
    – J.Todd
    Jun 24, 2014 at 20:08
  • 1
    @jt0dd in most cases it's only few lines of code, so using SPACE is really not that hard. If it involves more code, well, it better be tested first anyway so we're back to my previous argument. I wrote hundreds of code samples, so talking from experience not just empty opinion. Jun 24, 2014 at 20:13
  • @ShadowWizard provide that as an answer, if you wish. I'm interested in knowing the argument of a wide range of Stack Exchange Users. No's and Yes's are both welcome, reasoning provided.
    – J.Todd
    Jun 24, 2014 at 20:14
  • 1
    @ShadowWizard Isn't Meta SE 'primarily opinion based' as it is? Jun 24, 2014 at 23:39
  • Cross Posted on UX
    – J.Todd
    Jun 24, 2014 at 23:59
  • @justcool393 yes, but to a limit. This is a very gray zone though. Jun 25, 2014 at 8:16
  • @Oded Shift + Space ?
    – J.Todd
    Jun 26, 2014 at 22:45
  • This question overlaps with adding indent/outdent buttons to the editor.
    – AD7six
    Jun 26, 2014 at 23:26

4 Answers 4


As a developer who focuses on UX, I disagree, on the grounds that I believe that when editing code, TAB is expected by most users to create a tab, not jump to the next element in the page.

I agree! When I'm editing code in my development environment, I'd like tab to create indentation. (In my case, four spaces rather than a tab character.)

However, when I'm writing my post, I'm not in my development environment, and I'm not editing code: I'm writing a post for a website. I expect my text box to behave like a text box. I expect to be able to tab out of it. I also expect that my key bindings won't magically change because I've started a line with four spaces or written <code> in my post - as a UX developer, you may recognise why this is not a great experience.

Now, my answer might contain code, but I don't expect to get any serious programming done in this editor I'm typing in anyway: I expect to get it done in Visual Studio, or Sublime Text, where I write my code before pasting it here. Also pertinent, in my case, is the fact my answers rarely contain code: the SE sites I use most frequently are ones that have nothing to do with programming, and even on Stack Overflow I'm more interested in theory-based questions and answers which contain little to no code (like these: 1 2 3 4).

Now, donning my own UX hat...

I'm a user experience designer and web developer who's presently deeply involved in accessibility and helping a site conform with W3C's Web Content Accessibility Guidelines 2.0. This means my job is about making sure those who are blind, have limited mobility, or so on can use the site effectively and have a great user experience.

A large portion of this concerns blind or visually impaired users who rely on a screen reader and keyboard controls to read and get around a page. Hijacking the tab key is one of the best ways to make that difficult or impossible for them, especially within a form control. Doing this is called a keyboard trap. A user who doesn't know the proper hotkeys to get out of a keyboard trap may need to simply reload the page and hope not to run into it again. This is a big concern when the keyboard trap in question is one of the most heavily used features on the site: the text box for writing and editing questions and answers, in its various incarnations.

This is a big deal, and one of the WCAG success criteria is aptly titled: No Keyboard Trap. It requires you to make special provisions if you create an element that "requires more than unmodified arrow or tab keys or other standard exit methods" to get out of. It's better to not be in that situation in the first place.

For the rest of us, we can go do our serious code editing in a serious code editor.

  • In response to the keyboard trap, I thought of this, which is why I personally chose to suggest that the editor behave this way between <code> tags only. In UX I find there is always a compromise.
    – J.Todd
    Jun 25, 2014 at 3:54
  • @jt0dd but then what about keyboard-only users who have started entering code too? How would they get back to native browser controls?
    – JonW
    Jun 25, 2014 at 9:46
  • Presumably, they get informed their tab key's rebound somehow, hopefully when they enter the code section. That's problematic though, especially for screen reader users: they'll be busy typing or trying to read the content of the editor, both of which will be likely to interrupt attempts to notify them of what's going on via screen reader speech. Jun 25, 2014 at 9:49
  • The thing is, nobody uses the code tags or needs them. Users will normally just indent or back-tick for code. The tags would simply provide a nice quirk for users who find themselves wanting to write a code example on the spot. @JonW
    – J.Todd
    Jun 25, 2014 at 18:25
  • I would suggest that there are enough people who want this functionality to justify making it a user preference.
    – Zev Spitz
    Apr 2, 2017 at 5:26

No, I don't think it will improve the user experience.

Personally, I never treated SE's editor as IDE, just ordinary text box allowing little formatting.

Code should be indented before posting and I find it totally sensible. JSFiddle is meant to write code from scratch, so IDE-like behavior is expected and important.

Users should not write code from scratch in Stack Overflow, but rather post existing code, which is expected to already be formatted/indented.

In case user want to answer with code sample, there are two common cases:

  1. Short code sample, few lines of code: easy enough to indent manually.
  2. Long code sample: better be tested first anyway, so user will use IDE first anyway.
  • Re: Your 2., when I post code in Python as an answer, I never go to an IDE/editor, but paste the lines from SE into the interpreter if testing is needed. This is a very natural workflow for REPL. (Pasting the other way is a bitch, because of the prompt.) Just a data point.
    – otus
    Jun 25, 2014 at 19:54
  • @Asad so why not write in a full scale IDE then copy to the answer box? IDE would also give you colors and auto indentation, out of the box. Jun 26, 2014 at 6:26
  • @Asad TAB inside a web page for me is expected to jump to the next element. The editor is still such an element. I have no problem if they will add auto indentation feature but changing the TAB key functionality will be more confusing than helpful in my opinion. I won't fight such decision if the team will do it, just saying why I support their current stand which is "we don't want to add it", as Oded said before already. Jun 26, 2014 at 8:21
  • I agree with @Asad -- Why should the fact that you can do something with 3rd party software ever mean that it isn't a good idea to offer the convenience where it's helpful? It's a convenience, and it's advantageous.
    – J.Todd
    Jun 26, 2014 at 21:56
  • [Shift + Space] = Space x 4 -- There. What's the harm?
    – J.Todd
    Jun 26, 2014 at 22:50
  • No harm, @jt0dd, it's something "nice to have" for some, and confusing for others, that's what I try to say all along. We have different opinion, but Oded is the one you should really convince. :) Jun 26, 2014 at 22:53
  • I'm gonna try, haha. The thing is, I get your argument if it were to damage something or confuse people, but Shift + Spacebar I think offers a perfect solution that solves the problem with damaging anything or confusing anyone.
    – J.Todd
    Jun 26, 2014 at 22:55
  • 2
    Users should not write code from scratch in Stack Overflow - I've written hundreds of answers on SO, most contain code (probably half of those are "Long code sample") and of those almost all of them will have been written from scratch in the browser.
    – AD7six
    Jun 26, 2014 at 23:33
  • @Viziionary [SHIFT+Spacebar] is another shortcut to remember, when most IDEs use just [TAB] by default.
    – Zev Spitz
    Apr 2, 2017 at 5:29
  • @AD7six Since this would be really nice to have for many users, but with valid reasons not to offer it by default, why not make it a user preference, but not enabled by default?
    – Zev Spitz
    Apr 2, 2017 at 5:32

Yes, as a user preference

I think this should be offered as a user preference (similar to keyboard controls); the behavior should be off by default. This avoids the keyboard trap.

Users who prefer this functionality will be able to choose it, even though it breaks the browser functionality.

Given the number of times this feature has been asked about (5 duplicates, listed here), I think making it a user preference is a reasonable solution.

As to how this could be implemented across sites, it should probably (if possible) only be available on specific sites, similar to how Developer Story is only available on SO.


Yes, I think it will improve UX if targeted properly.

I think any time a convenience can be added for a wide range of users, it's worth putting some thought into. Here is one solution I've thought of that allows the solution to target the users who want the feature.

What about enabling TAB's formating <code> between code tags? </code>

<code> If I were to hit TAB now, it would result in 4 spaces. </code> But not outside of the tags.


  • Avoids a keyboard trap. Impaired users can easily avoid using <code> tags, and if they do use them, navigating away from them can be done with arrow keys.

  • It doesn't affect the editor's primary functionality. It targets users who have searched the tab issue and found that tabs work for formatting! <code> between code tags :) </code>

  • The code for the feature is actually simple and fairly short. it can be done in just 365 characters [365 bytes]. Credit 100% to dandavis for this solution.

Try Before You Buy

Go ahead. Put it into the JS console of any Stack Exchange question page, and <code> use tabs between code tags! </code>. Or try the JSFiddle.

$("textarea").keydown(function (e) {
    var t = this.value,
    n = this.selectionStart,
    r = [t.slice(0, n), t.slice(n)];
    if (e.keyCode == 9 && t.indexOf("</code>", n) != -1 && t.lastIndexOf("<code>",
    n) != -1) {
        this.value = r.join("   ");
        this.selectionStart = this.selectionEnd = n + 1;
  • What's wrong with hitting tab giving a \t, kind of like what it's supposed to do? Jun 24, 2014 at 23:40
  • The primary argument is to preserve the default functionality of Tab in a web browser. So I suggest that the functionality stay as it is, except when SE knows for sure that we're editing code. Then it's safe to say that we want to use Tab for formatting purposes. Using <code></code> to target the functionality within the text editor would be a clever solution. @justcool393
    – J.Todd
    Jun 24, 2014 at 23:43
  • I was unclear, I was trying to ask why insert 4 spaces, when you can insert the tab character? Jun 24, 2014 at 23:45
  • I'm not sure that \t would have the same result @justcool393
    – J.Todd
    Jun 24, 2014 at 23:48
  • 2
    Mixing HTML and markdown is a path to madness and frustration. We already discourage it now and I don't see us implementing a feature that relies on it.
    – Adam Lear StaffMod
    Jun 25, 2014 at 19:33
  • Huh? <code></code> already works -- 365 bytes added to the script plus another line to make code tags create a full island instead of behaving like backticks, and wham! We lazy people are happy! @AnnaLear
    – J.Todd
    Jun 25, 2014 at 19:56
  • It works, but it's not guaranteed to work. Wouldn't be the first time HTML interfered with Markdown parsing around here. Mixing formatting mechanisms in the same post is a suboptimal idea, building a feature that encourages/requires doing so is even worse.
    – Adam Lear StaffMod
    Jun 26, 2014 at 18:21
  • @AnnaLear of course, it's just my idea. Would you be averse to adding the formatting for tabs if a better method were presented? (A method that didn't cause a change to the full system, nor cause a keyboard trap)
    – J.Todd
    Jun 26, 2014 at 20:22
  • 2
    @jt0dd Depends on the method and the community support it gathers. I personally never found a use for this - I paste in formatted code, and if I ever need to edit something long, I just drop it into Sublime Text and get it done in a fraction of the time it'd take me to do it in the browser no matter what. As Shadow Wizard says, we aren't an IDE. Further, we'd be potentially introducing different textbox behaviour on different sites (there's no need for easy tabs on Cooking, for example), and that's something to consider as well.
    – Adam Lear StaffMod
    Jun 26, 2014 at 20:26
  • @AnnaLear Shift + Space
    – J.Todd
    Jun 26, 2014 at 22:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .