Live data from Hacker News

IBM didn't want Microsoft to use the Tab key to move between dialog fields

devblogs.microsoft.com

61–70 of 250 posts

Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields

#61
post #14

As someone who prefers tabs (I'm not looking to argue), I once asked Brendan Eich on Twitter why he prefers spaces. His answer was more thoughtful than I'd expected. The tab key itself is hijacked by modern OS/UI behavior. It makes it complicated to actually type literal tab characters in certain contexts, particularly in the browser. I still prefer tabs (and I'm a Go developer), but he is absolutely correct about th…

There's also the fact that no one seems to have tab stops set the same way.

Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields

#62
post #58

Earlier quoted context omitted.

> I would guess that using the tab key in this way was part of a patent they were pursuing and Microsoft's use would show this to be 'obvious' and thus not patentable. Something that's bothered me about user-facing patents: Let's assume that the idea of using a keyboard key to move between input fields in a software form is not obvious, and in fact is a brilliant stroke of genius the likes of which the world is not l…

You can say the same about swipe to unlock and that had been litigated to death.

I did say the same about swipe-to-unlock:

>> Something that's bothered me about user-facing patents

Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields

#63

A great read, although I'd still like to know what IBM's reasoning for opposing this use of the Tab key was. Is it because they didn't want Tab to be both an input and a control character? I.e. there are some cases where you can type a Tab into an input field, and there are other cases where you can't, and it's not immediately obvious which ones are which? All the way in 2026, I would still be sympathetic to this vie…

The way I interpreted it was that there was no complete "IBM" reason. I read it as "one person in the IBM bureaucracy stepped in and brought things to a halt, which highlights the cultural differences" considering it is a post about said differences.

Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields

#64

Earlier quoted context omitted.

Non english speaker trying to wrap my head around what Brendan said to you. I was once told that the tab key can be represented in different ways on different systems, and that's why spaces are safer because they're always represented the same. Is that what Brendan was trying to say?

Brendan Eich was making a point about the tab key also being used to switch to different text fields and buttons. This makes it difficult to type in certain applications. A space doesn't have that issue. About your point of tab being represented different on different systems: It will always be ascii 9, how it's draw does differ between text editors but I consider that one of it's strengths for programming. Everyone…

Little irritates me more than logging into a new system, opening up code in vim, and witnessing the insanity of tabs-as-8-spaces

Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields

#65

A great read, although I'd still like to know what IBM's reasoning for opposing this use of the Tab key was. Is it because they didn't want Tab to be both an input and a control character? I.e. there are some cases where you can type a Tab into an input field, and there are other cases where you can't, and it's not immediately obvious which ones are which? All the way in 2026, I would still be sympathetic to this vie…

If you're designing a text editor that's intended to run within a browser you need to fully break user expectations about the functionality of the tab key - there are two completely logical and intuitive roles it can serve in such an environment that are in conflict.

The same issue arises (with much higher frequency) with Enter and even in the modern world I'm sure we all have a pretty complex ruleset we've committed of when ctrl+crlf triggers a newline, or a message send and what the corresponding behaviors of a bare crlf and shift+crlf are.

In HN's editor shift+crlf and a bare crlf cause a newline creation and ctrl+crlf does nothing - but often times ctrl+crlf will trigger a form/message/whatever submission, shift+crlf often causes a raw newline insertion (even when in a form context) and then a bare crlf might do one - might do the other or might even do neither! Those are the common bindings but I have seen exceptions and inversions of bindings with shift+crlf causing form submission while requiring ctrl+crlf for raw newline insertion.

All this stuff is just super annoying and causes a lot of user friction (and for a long time MSFT's style guide was considered a seminal reference for best practices as ironic as they may seem to folks these days).

Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields

#66
post #14

As someone who prefers tabs (I'm not looking to argue), I once asked Brendan Eich on Twitter why he prefers spaces. His answer was more thoughtful than I'd expected. The tab key itself is hijacked by modern OS/UI behavior. It makes it complicated to actually type literal tab characters in certain contexts, particularly in the browser. I still prefer tabs (and I'm a Go developer), but he is absolutely correct about th…

There's also the fact that no one seems to have tab stops set the same way.

That's a feature, not a bug.

Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields

#67
post #51
post #13

I find this story odd because IBM was consistent with their keyboard nomenclature across multiple products, and the 3270 series mainframe terminals used the Tab key, located in the same place where you would find a tab key on a modern keyboard, to move the cursor to the next field. https://www.bitsavers.org/pdf/ibm/3278/GA27-2890-4_3278_Disp... (Page 73 of the PDF) As an aside, it's worth noting that moving between f…

From what I remember, there were two "Enter/Return" keys on IBM 3270 terminals. One was the regular "Return" key we have today, which just advanced to the next field, and didn't submit the form. There was also another "Enter" key where the Right Ctrl key is today, and that submitted the form. So, I presume, instead of being against Tab key, IBM might be against "Return" to be the form submit key as people who use 327…

Your memory is correct, and it's interesting to note that on the IBM terminal keyboards, the Enter key was marked "Enter", and the return/new line key was marked "↵". On the classic IBM PC keyboards such as the Model M, the Enter key is marked "↵ Enter". I believe IBM chose this to convey that the Enter key on the PC was both an "Enter" _and_ "Return" key in one. As you say though - individual applications got to chose what that meant in practice, leading to inconsistent behavior.

Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields

#68
post #16

Earlier quoted context omitted.

I'd never really thought about it before, but Enter to advance to the next field field and Ctrl + Enter to submit the whole form (which is the typical keyboard shortcut for submitting the form while a multi-line text input control has focus) does have a certain appeal to it.

The overloading of return to either send a message or add a newline has become really annoying since chat apps (and then now AI) have become popular. You have to keep a mental context of whether you need to hold shift before you press return. See also: every message I've ever sent that ended with I' because I fat-fingered the ' key while typing a contraction.

Shift+Enter will usually enter a newline in a message without triggering send... At least that's the convention used most of the time. No guarantees on specific applications, just my own experience with this.

Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields

#69
post #13

I find this story odd because IBM was consistent with their keyboard nomenclature across multiple products, and the 3270 series mainframe terminals used the Tab key, located in the same place where you would find a tab key on a modern keyboard, to move the cursor to the next field. https://www.bitsavers.org/pdf/ibm/3278/GA27-2890-4_3278_Disp... (Page 73 of the PDF) As an aside, it's worth noting that moving between f…

Funnily enough, IBM had already published this. CUA explicitly says tab and backtab move between fields.

so they spent seven layers of management escalating against their own standard: https://archive.org/details/ibmsj2703E/page/n13/mode/2up

Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields

#70
post #14

As someone who prefers tabs (I'm not looking to argue), I once asked Brendan Eich on Twitter why he prefers spaces. His answer was more thoughtful than I'd expected. The tab key itself is hijacked by modern OS/UI behavior. It makes it complicated to actually type literal tab characters in certain contexts, particularly in the browser. I still prefer tabs (and I'm a Go developer), but he is absolutely correct about th…

The fact that most people think the Tab key is the correct choice is a perfect example of why it was not.

It had a purpose, and it got hijacked and made its actual purpose more difficult to use.

It's not dissimilar to Apples initial Touch Bar and then removing the Escape key.

Average user might never use that key; average developer doesn't got long without using that key for its purpose.

Post reply on HN