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…
IBM didn't want Microsoft to use the Tab key to move between dialog fields
61–70 of 250 posts
Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields
#62Earlier 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.
>> 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
#63A 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…
Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields
#64Earlier 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…
Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields
#65A 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 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
#66As 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
#67I 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…
Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields
#68Earlier 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.
Re: IBM didn't want Microsoft to use the Tab key to move between dialog fields
#69I 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…
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
#70As 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…
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.