34

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.

Advantages


  • 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;
        e.preventDefault()
    }
})

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;
        e.preventDefault();
    }  
});

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.


17
  • 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. Jun 26, 2014 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, 2014 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, 2014 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, 2014 at 4:07
  • I think our talented SE devs will be capable of such tweaks without issue.
    – J.Todd
    Jun 27, 2014 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. Jun 27, 2014 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, 2014 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. Jun 27, 2014 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, 2014 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. Jun 27, 2014 at 6:50
  • @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.
    – J.Todd
    Jun 27, 2014 at 12:52
  • "requires some sort of indicator" the add-on makes the text area grey to indicate it.
    – ADTC
    Jun 27, 2014 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!
    – J.Todd
    Jun 27, 2014 at 13:14
  • According to the creator of that user script: The "press and release Ctrl before pressing Tab" hack (or something along those lines) is okay for someone consciously making the decision to install a user script. But not for the core functionality of a website.
    – J.Todd
    Jun 27, 2014 at 13:27
  • I agree with your points but I still don't think "Shift Spacebar" is a good idea, as it's not a standard. I think we should leave users to find their unique way of doing indentations, rather than have the site cater to everyone (including those who use the accessibility shortcuts) with just one feature.
    – ADTC
    Jun 27, 2014 at 13:31

2 Answers 2

1

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

https://blog.stackoverflow.com/2014/09/introducing-runnable-javascript-css-and-html-code-snippets/?cb=1

-6

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?

9
  • 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.
    – J.Todd
    Jun 27, 2014 at 19:17
  • What is wrong with \t? Jun 27, 2014 at 19:46
  • Users here use spaces, not tabs, and you do not mix them. @justcool393
    – J.Todd
    Jun 27, 2014 at 22:54
  • @jt0dd I'd use tabs if I could, but I can't, because it tabs over to the next element. Jun 27, 2014 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
    – J.Todd
    Jun 27, 2014 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, 2014 at 15:05
  • @jt0dd That's what I meant too. I use \t for my tabs. Jun 28, 2014 at 22:03
  • @Arjan I'd use if it was with 8. Jun 28, 2014 at 22:05

You must log in to answer this question.

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