Live data from Hacker News

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

devblogs.microsoft.com

41–50 of 250 posts

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

#41
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?

> 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.

The main counter argument is that users have different preferences for the amount of indentation, so giving them control over that, just as they (nowadays) have control over the font used and window width, is a good idea.

The tongue-in-cheek counter argument is that fixed-width spaces are preferable over ‘normal’ spaces. They also give you more control over indentation, allowing, for example, mixing usage of THREE-PER-EM SPACE (https://unicode-explorer.com/c/2004) for indentation with FIGURE SPACE (https://unicode-explorer.com/c/2007) for right-aligning numbers.

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

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

Also conspicuously missing from the story is what key IBM DID want to use. I mean... that's the first question you'd ask! Lame.

Ctrl-F6 ?

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

#43

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?

Literally try entering a "tab" character in a Hacker News reply. For me in Safari, it changes the focus to the "reply" button. It's literally difficult to enter a "tab" character into many text entry fields and dialogs and applications, because it's used so often as a navigation key.

[deleted]

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

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

Here's a real IBM 3270 keyboard.[1] Note the "Next field" key on the left, and the matching "Previous field" key on the right.

The IBM 3270 was a device for filling up forms. The mainframe sent the terminal a form with blanks, and the terminal let the user fill in the blanks. The terminal hardware prevented the user from overwriting the static parts of the form, and could apply some other form constraints, such as numeric fields. That was all done by the terminal. When the form was filled in, the user pressed ENTER, and the completed form was sent to the mainframe as one transaction. This approach let one mainframe service huge numbers of terminals. The user never experienced delays while typing and could type at full speed, often without looking.

PCs didn't have that usage model. The PC crowd was thinking "typewriter". One of the first terminals for home computers was called the "TV Typewriter".

Web forms do have that model, but with less consistency.

[1] https://sharktastica.co.uk/resources/images/model_bs/themk_1...

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

#46

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?

No he's saying if you're trying to write code in an edit box in a web browser (for example) and you press tab, instead of inserting a tab character it will move the focus to the next input field. Bullshit reasoning though, because even people who use spaces for indentation don't do it by hammering the space bar - they also press the tab key. And of course in modern browsers we can give tab the expected behaviour. The…

[dead]

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

#47
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?

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 can configure what an indent looks like for them, it makes reading code easier.

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

#48
post #35

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?

Tab key is both a control character moving the cursor to the next input and also an input representing the tab character as you see in a text editor. Now that im thinking about it I’m convinced capslock would have been superior next field key and alt+capslock to be used for toggling capslock. But it’s not obvious to me capslock [e: must be] seen by the OS. It could be changed on the keyboards themselves.

It definitely is visible, OS login screens usually warn you if caps lock is on when typing password

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

#49

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

I wonder about the midrange systems. I never used AS/400's, but I know they have the concept of a a "Field Exit" key separate from .

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

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

It might be reasonable to have a separate key for "tab" vs "next field", as well as separate key for "line break" vs "send". (But, tab and line break are not applicable for all contexts.)

However, it might also be reasonable to have a key or key combination (some programs use ^V) to enter control characters as data rather than as commands.

It might also be a consideration when designing a new computer (which does not have to be the same as existing ones); I had thought about such things and may make such a consideration.

Post reply on HN