I asked a discussion question about whether or not giving tabs formatting functionality would improve UX, and after trial and error on this solution, would like to present it as a feature request.

According to Anna Lear ♦︎, if we get some support for a method of doing this that doesn't screw anything up, cause problems, nor damage tab order, we might be able to say goodbye to hitting the space-bar 4 times for good.

Here's my solution. Should it be implemented in SE?

Easy tab formatting with key combo Shift + Space

While using <code></code> to target the easy tab formatting (it was my first suggestion) is a bit rough around the edges, I think you'll find that Shift + Space offers a shortcut that appears to have no downside.


  • No keyboard trap. It doesn't affect Tab Order in any way.

  • Doesn't break anything. No native functionality in textarea nor OS (that was the issue with Alt + Tab in Windows 8) uses this key combination.

  • Doesn't require an interface change. This solution is silent, and therefore can be utilized by anyone who wishes to use the functionality without bothering anyone who doesn't.

  • The code to do this is minimal. Like my other suggestion, the solution is barely over 300 bytes added to the site. Again, credit to dandavis for the original code.

Try it for yourself right now in SE

Go ahead. Put it into the JS console of any Stack Exchange question page, and use Shift + Space for your formatting tabs. 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.shiftKey && e.keyCode == 32) {
        this.value = r.join("    ");
        this.selectionStart = this.selectionEnd = n + 4;

Fancier Version... These features aren't part of the feature request!! I'm happy with simply getting the raw shortcut, however, after adding the suggested "bug" fixes and having the code reviewed, this version demonstrates some features worthy of consideration. Here's a nice, well written version after review by David Harkness, demonstrating additional functionality (I've re-uglied it since his review):

$("textarea").keydown(function (e) {
    if (e.shiftKey && e.keyCode === 32) {
        var pad = "    ",
            text = this.value,
            start = this.selectionStart,
            end = this.selectionEnd,
            scroll = this.scrollTop,
            before = text.slice(0, start),
            after = text.slice(start),
            selection = text.slice(start, end),
            prevChar = before.charAt(before.length - 1),
            prevFourChar = "",
            beforeLess = before.slice(0, start - 4);
        if (e.ctrlKey) {
            for (var i = 1; i < 5; i++) {
                prevFourChar += before.charAt(before.length - i);
            if (prevFourChar === pad) {
                selection = selection.split("\n" + pad).join("\n");
                this.value = beforeLess + selection + after;
                this.selectionStart = start - pad.length;
                this.selectionEnd = end - pad.length;
        } else if (prevChar === "" || prevChar === " " || prevChar === "\n") {
            selection = pad + selection.split("\n").join("\n" + pad);
            this.value = before + selection + after;
            this.selectionStart = start + pad.length;
            this.selectionEnd = end + pad.length;
        this.scrollTop = scroll;

This version demonstrates the inclusion of:

  • White-space, newline, and line-start targeting, eliminating accidental misuse in the case of hitting space-bar after holding shift to capitalize a letter.

  • Outdenting support with Ctrl + Shift + Spacebar (Alt + Shift + Space has a collision with a native Windows 8 shortcut).

  • Multi-line support, allowing a larger selection to be indented and outdented, sort of replacing Ctrl + K to keep the functionality all together with those three keys.

Alternate Shortcut Keys that use Shift for Outdenting

As mentioned in this code review, Shift is normally used to reverse the functionality of a key combo. The only suitable option that adheres to this pattern without any shortcut collisions (that I know of) is:

Indent: Ctrl + Spacebar

Outdent: Shft + Ctrl + Spacebar

Both combinations are comfortable to use based on key position. This one simply offers conformity to Shift's customary functionality.

  • 7
    +1 This sounds like a fantastic solution. Shift+space doesn't have any special binding inside a text box, not even in screen readers. – doppelgreener Jun 26 '14 at 23:42
  • 1
    One downside I can see if if I were typing something like “XML is…” There, I might inadvertently hold down shift while typing the space after the L, inserting four spaces. It’s not harmful there, but it’s not something I’d want to put in, either. – icktoofay Jun 27 '14 at 4:00
  • Another concern is that it would interact negatively with IMEs. I tried it with an IME locally, and there were no negative effects, but there may be other IMEs that do not play so nicely with it. – icktoofay Jun 27 '14 at 4:04
  • 3
    Something that would work around both of those problems (probably) would be to make it only work if the only characters before the cursor on the same line are whitespace. Then you can use it for indentation, but it won’t unintentionally fire when you’re in the middle of a line. – icktoofay Jun 27 '14 at 4:07
  • I think our talented SE devs will be capable of such tweaks without issue. – Viziionary Jun 27 '14 at 4:38
  • 3
    Should this insert a tab or four spaces? Your jsfiddle inserts tabs, your code sample inserts spaces. I'm inclined to say four spaces, because that's what the people who don't use this feature will be using, and more important than one or the other is to keep things consistent. – doppelgreener Jun 27 '14 at 5:13
  • "Doesn't break anything.", actualy, Shift + Space is jump up, inverse of Space; or you mean only on edit field? Just some clarification. – m0nhawk Jun 27 '14 at 6:13
  • 1
    @m0nhawk It's only in the edit field. See the code sample, which only responds to keystrokes in a text area, namely the question/answer editing text areas. – doppelgreener Jun 27 '14 at 6:21
  • 2
    Personally I find that using Tab key itself for indentation is better than gimmicks like this. It's natural, and consistent. I use this user script add-on from StackApps and it works great for me. I don't normally use Tab key to move between elements on page, but if you do, you can always hit the Ctrl key in the edit box (text area) to temporarily disable the add-on. Just my $0.02. – ADTC Jun 27 '14 at 6:33
  • @ADTC Ctrl+tab is a browser tab shift, though, and shift+tab and alt+tab are also meant to have their own purposes. It's great it works for you as a user-enabled feature, but rebinding tab globally for everyone on the site has significant accessibility concerns. – doppelgreener Jun 27 '14 at 6:50
  • @JonathanHobbs to clarify, when using the add-on you don't press Ctrl-Tab to go to the next element. You press Ctrl (not hold it) to disable the add-on (the text area becomes grey) then hit Tab as you normally would to move to the next element. And yes, site-wide changes for everyone can get confusing... But what about SE sites offering "Preferences" for users to either enable such selected features manually, or install scripts on their user account (both of which will show up on any browser or computer they use to log in to any SE site)? Wikipedia already does this, so it's possible. – ADTC Jun 27 '14 at 6:56
  • Ok, that makes sense. So ctrl then tab rather than ctrl+tab at the same time. – doppelgreener Jun 27 '14 at 6:58
  • @ADTC the whole point is to suggest a feature that doesn't require a site-wide change. No extra preferences, no interface change. Just a non-damaging shortcut. Ctrl THEN Tab requires some sort of indicator in the interface to inform the user of which mode he/she is currently in. – Viziionary Jun 27 '14 at 12:52
  • "requires some sort of indicator" the add-on makes the text area grey to indicate it. – ADTC Jun 27 '14 at 13:02
  • That's probably more of an interface change than SE is willing to make. This way, we at least get the feature we've been wanting -- it's hard to decline a feature that's beneficial, easy, and has no negative effect. But you want us to make a non-labeled interface color change to represent a feature based on a key that someone might press by accident and not understand what's going on? DECLINED! – Viziionary Jun 27 '14 at 13:14

And now, we discover the reason that SE ignored this post. They had something much bigger and better in the works:



Just add a button in the kitchen sink above the editor that toggles whether or not the tab key inserts 4 spaces.

It's impossible to tab to the kitchen sink so it would require someone that doesn't tab around to everything to enable it.

It would be off by default when the page loads for accessibility. Once you click the button you can tab and insert four spaces to your hearts content.

Then if you really want to press tab to get out of the editor, you can press the button and do so.

Does this solve everyone's concerns?

  • 1
    No. SE denied the original feature request for this kind of thing. Hence we're pushing a silent, simple solution, with no downside. Adding a button to the site's text editor is a big deal and will likely not happen for this feature that a limited number of users want. The best way to pass such a feature is going to be by ensuring that its implementation does not bother the people who don't care for it. Cluttering up the kitchen sink would certainly draw a negative response from users who don't need it. – Viziionary Jun 27 '14 at 19:17
  • What is wrong with \t? – Justin Krejcha Jun 27 '14 at 19:46
  • Users here use spaces, not tabs, and you do not mix them. @justcool393 – Viziionary Jun 27 '14 at 22:54
  • @jt0dd I'd use tabs if I could, but I can't, because it tabs over to the next element. – Justin Krejcha Jun 27 '14 at 22:55
  • That isn't the point. By tabs I mean \t. Stack exchange uses 4 spaces to represent tabs, not \t, and the two methods should never be mixed. @justcool393 – Viziionary Jun 27 '14 at 22:56
  • @justcool393, would you use tabs if your browser displays them using a width of 8? (SE uses 4 spaces for a tab when displaying, so IE not supporting CSS tab-size is no issue there. But while editing, both IE and Firefox do not support tab-size for textarea either. Chrome and Safari do support it.) – Arjan Jun 28 '14 at 15:05
  • @jt0dd That's what I meant too. I use \t for my tabs. – Justin Krejcha Jun 28 '14 at 22:03
  • @Arjan I'd use if it was with 8. – Justin Krejcha Jun 28 '14 at 22:05

You must log in to answer this question.

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