Live data from Hacker News

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

devblogs.microsoft.com

11–20 of 250 posts

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

#11

Weird because on the mainframe 3270 the tab key was used to move between fields, at least that is my recollection.

It's been ages since I used an IBM green screen but I seem to recall that in our application Tab did move between fields, but I think there were also function keys reserved for this purpose.

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

#12

Weird because on the mainframe 3270 the tab key was used to move between fields, at least that is my recollection.

That's exactly my memory too, using a tab was second nature and it irked me when I went to gui apps with a mouse and the tab order was wrong, mainly with visual basic apps.

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

#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 fields was important enough on IBM terminals that they had a dedicated "back tab" key located on the opposite end of the keyboard to the tab key. On the original IBM PC, they decided to combine both functions into a single key. As a result, the tab key on the classic PC keyboard features the symbols for both forwards tab and back tab on the same key, the back tab symbol being on top to indicate that you need to hold down shift to use that function.

EDIT: The 5250 series terminals used the terms "Field Advance" and "Field Backspace" instead of Tab and Back Tab, but otherwise they used the same symbol on the keys, and the keys were located in roughly the same position as the 3270 series. Reference: https://www.bitsavers.org/pdf/ibm/5291/GA21-9409-0_5291_Disp...

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

#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 that being a pain in the butt. For instance, try getting a tab character into the text area on Hacker News

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

#16

What did IBM want? Arrow keys?

Enter/return commonly used elsewhere.

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.

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

#17

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…

I assume so. Obviously there are very different concerns if you're managing an organization with countless moving parts versus you want to build something for the user quickly.

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

#18

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…

I now imagine a world where CAPSLOCK is used as "select the next input" and TAB as the character.

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

#19
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…

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?

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

#20

Earlier quoted context omitted.

Enter/return commonly used elsewhere.

What would be 'submit' then?

Enter/return on the 'Submit' button, I suppose. The rationale may have been "Start at the beginning of the form, keep hitting Enter after filling in each field, and it will submit itself when you're done."
Post reply on HN