I do not have sufficient profanity in my verbal arsenal for websites that override basic, fundamental browser behaviour because they think they know better than I do what I actually meant to do. I have noticed Medium being a regular perpetrator of this sort of broken behaviour before.
That one of the developers at Medium could run into such a glowing example of one of the many reasons it's nasty to override browser behaviour, and take the lesson from it that oh hey, we just need to make our override logic more complicated... the blindness and idiocy and sheer bloodymindedness of this response I just can't even.
While for the most part I agree with you, there are sometimes when it seems... appropriate. Take, for example, Google Docs. I'm used to hitting CTRL-S when working on just about any paper. If I had the save website dialog pop up every time I hit CTRL-S, I would start to get annoyed. I'm glad that Google Docs doesn't do that. A similar case can be made here.
I wonder if the shortcut should be removed. Certainly some people use the feature, but it seems obscure enough that maybe we should pass that combination on to the website, instead.
Though you get an html file and a folder with all the external assets, which I find to be pretty annoying. Safari did a single .webarchive file, but I don't think anyone else ever standardized on something like that.
It often wrecks the layout, but I tend to print to PDF rather than deal with saved html files.
Save-As writing bunch of resources, that when loaded back into the browser might even be broken by lack of external resources are also, in my oppinion, a bad way to keep evidence (e.g. CYA). If you need it to persuade a non-computer-savvy person of something stated on a website, I'd say a bunch of random files in a directory is also much less convincing than a "printed-to" pdf, or screenshots you can easily mail around.
Regarding the .webarchive, I think IE supports another type of "web archive", with a .mht ending.
If you ask me web browser's stole CTRL+S! It used to mean "save my work", but in a browser it means "download a copy of the website I am viewing", which seems totally different to me. I can't remember ever wanting that behavior.
I agree with you that websites shouldn't override useful browser behavior, but I'm OK with websites restoring CTRL+S to it's rightful meaning of saving my work.
Except, it generally doesn't mean that either. It means "download the page again and save that - nevermind if what I'm looking at has changed since it was retrieved". Which also breaks the mental model of "save my work", even if you're just typing text into a form.
Yes, you have all my votes. Words cannot describe the ire which consumes me when cute webdevs reinvent everything because it works on their industrial-grade computers with perfect internet. I agree. So. Much.
But.
It pains me to say this: what else would you want to have happen when a user presses Ctrl+S?
Are they really wrong, here? Wouldn't a user expect a "save blog" on Ctrl+S? How would I explain to a non-tech user why Ctrl+S works in Word, Excel, Powerpoint, but not in Medium?
Users who do "Ctrl-S" to do fast save are certainly a minority. (1) That minority can have somewhere in the configuration of the site the setting where they can turn the default off, but the default should really be for $deity sake, don't override the default behaviour!
1) I'm old enough that I've programmed the computers with the front panel switches bit by bit, but I've never used "Ctrl-S" as the "fast save" when writing documents. I don't know actually anybody who does. Autosave in Word functions as it should (not needing any user action) since at least 1998. My code editors and IDEs all do autosave too before compiling. What's the auctual benefit of ever using Ctrl-S in the middle of writing?
I've lost too much data to trust to autosave. When coding I don't want autosave, because I don't want my computer to be trying to compile all the time (I write Scala, I don't have the RAM to do that) - I want it to wait for an explicit Ctrl-S to tell it that I've finished a meaningful section and it should compile now. I have exactly the same thing on prose.io (which I write on a lot, and which looks very similar to medium), where "saving" means creating a git commit - I don't want an automatic commit for every letter I type, but I do want to commit very frequently, after each paragraph or similar unit. Rather like when programming.
It becomes a mental tic, an "I've finished the paragraph" instinct. And I'm very glad medium handles it.
What do you use actually that doesn't have "undo"? I can "undo" the whole day of my work on the file until I close it in the IDE. Whatever is "lost" I can return to the previous point.
If you're asking why I use git at all, my IDE crashes often enough that I don't want it to be my sole store of history; also I want that history available to my colleagues or my future self, weeks or months from now.
It's the way I'm used to working, I can't say how common it is. Put it this way: I want to control when it compiles, and I want it to be very obvious if the error markers aren't up to date. So the setup I currently have is eclipse with automatic compilation but manual saving; the possible states are saved and up to date, unsaved (obvious from stars in the title bar) or still compiling just after a save (obvious from progress in the status bar). When I tried to use IntelliJ with its autosaving I found I was pushing code to master that didn't even compile, because I would make a change and then not realize that this had broken something.
> Users who do "Ctrl-S" to do fast save are certainly a minority.
My first reaction: How else do you save?! You mean you actually take your hands off the keyboard, and click the floppy icon in a toolbar? Or even.. click on File > Save? Seriously?
I think this assumption as a very strong population bias.
With the people I work with.. it's all about keyboard shortcuts. If you don't know your basic keyboard shortcuts, you're too slow. But then again, I work around people with super customized Vim and EMacs configs and people who live in Photoshop/Illustrator all day. You just can't be productive in those environments without keyboard shortcuts.
For me, users who don't do "Ctrl-S" to save are certainly a minority.
Agreed. I also used ctrl-shift-p to preview Github comments with similar frequency while composing, and get frustrated when I get print dialogues in my mail window.
> I've never used "Ctrl-S" as the "fast save" when writing documents. I don't know actually anybody who does
I, for one, used to have this habit. The notion of "not knowing anyone who uses Ctrl + S" is a bit funny - are you really aware whether people around you do this or not? How does it come up?
By watching normal non-programmers people like my girlfriends and programmers people like my colleagues with whom I worked closely. Former just don't do any Ctrl-anything during the writing. The later simply never needed Ctrl-S, just like I. Autosave really works in the most common tool, Word. When my girlfriend lost her work, it was never for the autosave, but for manually saving over something she did before or Word corrupting the file during the save (the corrupted file was still luckily readable by OpenOffice).
By watching normal non-programmers people like my girlfriends and programmers people like my colleagues with whom I worked closely. Former just don't do any Ctrl-anything during the writing.
The actual benefit of using ctrl-S (or cmd-S for us Mac folk) is that autosave is still not ubiquitous, and I'd much rather press cmd-S regularly when it's not necessary than fail to press it and then discover that I needed it. The great thing is that it's basically instantaneous now so it costs nothing to press it every few words, which definitely wasn't the case when I acquired the reflex in the late 80s or early 90s.
For this particular default I see no problem in overriding it. I'm sure there's only a minority that routinely uses ctrl-S to save a lot, but essentially nobody uses ctrl-S to save a web page that contains a document they're in the middle of editing, given how esoteric that is and how unlikely it is to produce a useful result.
That's not to say that overriding defaults is good in general. But there's no need to be consistent about it. Overriding ctrl-S is totally different from overriding the arrow keys, for example.
I use some particularly crashy software at work, and even when autosave does work I have to play "Damn it, where did they put the autosave folder?" If I've saved in the last few minutes I can usually just redo it faster than finding the most recent save file.
It's a symptom of this latest "push all functionality to javascript" fad, and I can't wait until people wake up to the fact that it's just this generation's Flash.
In-browser WYSIWYG or markdown editing is not good UX design. Period. Full stop. It's never been better than an offline text editor, and when you try to present a cross-browser experience, this is what inevitably happens.
I wasn't around for it, but I feel like this same thing could be said for cross-platform compilers or VMs... Javascript is just newer. It seems like your argument in the second paragraph could be applied to the infant Java VM or GCC. It seems a little myopic.
I haven't used Medium, so I can't speak to it, but in my experience the most frustrating instance of this behavior is from Stack Overflow. Keybindings such as `Ctrl`+`k` and `Ctrl`+`b`, which are native to OS X, behave completely unexpectedly in Stack Overflow textareas, to the extent that I sometimes just give up and compose my text in an external editor.
I've grown accustomed to writing longer comments or posts in an external editor, simply because I've too frequently experienced browser crashes, or an inadvertent (or absent-minded) screen refresh. Alt-backspace is my worst offender, as I use that ALL the time in the shell for text editing, whereas in a browser it navigates backwards.
Worst of all, I can't seem to find a way to alter the keybinds, or (more importantly) the mouse-5-means-go-back gesture.
I'm not sure if it's happening now, but at one point in time F5 wouldn't work to reload the page if twitter is loaded.
And not to mention google plus, that swallows Ctrl+PgDown and Ctrl+PgUp, which happen to be shortcuts to move through tabs. So you are moving through tabs, then you suddenly stop, and you have to reach for the mouse.
What is the right approach to have the in-browser editor save? Users may want to manually trigger a save because it makes them feel safe before they close a browser tab.
While I sympathize with a lot of the "don't usurp the browser" arguments, this is really the correct answer. Whether or not it is logical, the fact is we are software developers who create software for USERS.
I think the article is too verbose when knowing the context the bug is trivial: you intercepted meta+s and ctrl+s and in the way you broke alt+s.
I find the save dialog useless for web browsers as well, but I think preventing its use is a bad idea in general. Overriding the browser's shortcut is uncomfortable. For example, wordpress likes to capture cmd+<number> to change the font style, but that's how I usually change the active tab. It also disables ctrl+tab, the other way I use to escape while the text area is active.
People use their browsers and have their workflow in them. Breaking them needs to have a really good excuse. http://xkcd.com/1172/
But the article explains why they override ctrl-s. It is because the users had muscle memory to keep hitting ctrl-s to save, since they were used to not having an auto-save function built in. But more than that, is the idea of a web browser as an app delivery platform. If a web browser is running an app (such as a word processor, or spreadsheet, or anything but browsing the web) it is sometimes necessary and beneficial to turn over browser-reserved keystrokes to the app in question. The only time to expect browser shortcut keys to work normally is when browsing a web page (vs. using the browser to run an application).
Indeed, allowing the browser's default Ctrl+S action to take effect would be actively harmful. It'd trigger a behavior that's completely useless to the user (saving the active web page as HTML), but which could easily be mistaken for doing something useful.
Pfft. Or you could just press Alt-Space, M, and then the arrow keys to "bind" the move to the mouse movement. This will let you bring the dialog back onscreen.
On second thought, I'll be glad when I don't have to know that.
The actual bug was trivial, the backstory was really interesting - it's the kind of thing you'd hear about on the 99% Invisible podcast. Sometimes verbosity is nice, after all, who doesn't like to share a good bug-hunt story?
Not mention the sites that hijack "/" for their search. I don't think there's a single site that hijacked keys which ended up being a good idea (at least from my experience).
I think browsers need option to disable key hijacking.
It'd drive me crazy if Gmail _didn't_ do that. Love the keyboard shortcuts, including and especially the ones that override. Highly productive compared to the alternative.
I dunno; I really preferred the alternative I used to have: reading email in a proper email client. The only reason I use the web client now is that it's easier when I'm also using my phone to read mail away from my computer. And I'm strongly considering just returning to desktop-only email; that's how much I miss reading mail in gnus.
At the time I was heavily using local groups (folders) to organise the emails, and of course those weren't living on Google's servers—and if I were going to leave them up on the server, I might as well choose to organise them differently, since I wouldn't have gnus filtering them for me.
And I think there was some trouble with IMAP at the time too, so the path of least resistance was to just use the web client on my desktop. But, as I noted, I'm thinking of going back.
I initially planned to put a TL;DR here, but it's the best bug analysis I've seen in months - a pleasure to read! - so I'm leaving it for others to savour.
The very same bug used to be present in early Windows mobile GPU drivers - with global hotkeys making it impossible to enter Ł (with Intel GMA 950) and Ć (with ATI Catalyst). Being a Polish geek, I used to earn lots of free dinners from frustrated friends who were forced to copy-paste those letters on their brand new laptops. Funny how the same bug recurs in different types of software due to an obscure locale-dependent edge case - and it's much less known than, for example, the Turkish dotted/dotless I.
> Our extra characters might look very much like Latin equivalents, and amount to only about 8% of letter distribution (you will hate them playing Scrabble)
Polish competitive Scrabble player here. It's not so much hate as a love-hate relationship. While it can be frustrating to be left with a vowelless rack containing a Ź in the endgame, for the most part these letters are quite desirable. Indeed, three of them (Ą, Ę, Ó) are vowels worth 5 points each, and only two of them (Ć and Ź) don't appear in any two-letter word. Even the Ź is fairly easy to get rid of, given an open enough (read: not completely blocked) board. They're nowhere near as irritating as the Q (and to a lesser extent Z) in English Scrabble.
Noticed similar issues with official Australian VISA / immigration pages. You can't simply fill some forms with your email address using Finnish keyboard. Why? Because they block usage of AltGr button on their page. They also prevent using clipboard blocking copy paste option for that sign. User has to be smart enough to switch to US keyboard and then enter @ sign and then switch back. So this is nothing new, but it's absolutely rude from part of the site designers to vandalize basic functionality like that. Normally @ is produced by AltGr + 2.
I guess they got BOFH department, let's make this really annoying and prevent people from getting their business done, laugh.
"While France, Germany, and other countries got their early PC with customized keyboards whose layouts mirrored closely the typewriters that came before… [...] …in Poland, we had to find another way of inputting the extra 9 diacritics unique to our language."
Did we? I dare to say that your historical account is inaccurate. We stuck to our traditional layout for a while.
What does it matter if the keyboard wasn't customized in physical sense anyway? You should be looking at the screen, not at the keys. If I recall well, Polish typewriter layout (PN-87) was still available on Windows 95/98. The now prevalent >Alt + something< one was called "programmer's layout", and the name itself indicates that it wasn't originally thought of as everyman's layout.
The typewriter layout finally got extinct, but what spelled its ultimate demise was the internet, I believe.
Early netiquette actually forbid using Polish diacritics, because of encoding issues - in that era you could never be sure whether the other person would read "gwóźdź" or "gw░¶d¶", so it was considered good practice to stick to Latin characters only.
Meaning that users didn't get to feel the pain of having to press Alt + whatever all the time, and so they got hooked on default QWERTY.
As the last of Mohicans, I use the typewriter layout to this very day (for typing in Polish; I alternate), only I had to recreate it myself (using Microsoft Keyboard Layout Editor)*
It allows for much faster typing in compare to these inconvenient right-Alt shortcuts. Swapping Y with Z by itself is a win for a Polish speaker (writer), given that Z is much more common in Polish. While its frequency is at mere 0.07% in English, it reaches 4.9% in Polish, placing it in the top 10. Thus putting it under the weakest finger of all - your left pinky - isn't very considerate.
-------
* Funnily enough - I'm not flame baiting - when I decided to try Linux, hailed for its customizability, I found out that recreating my favorite layout wasn't as easy. I got lots of advice on various forums, but noone had a simple receipt for me. Admittedly this was few years back.
It allows for much faster typing in compare to these inconvenient right-Alt shortcuts.
This is really interesting.
As a late-comer to Polish (native British), I've only learned on the right-Alt layout, and the typewriter layout initially gave me The Fear just looking at it.
Then I tried to see how quickly I could type Łódź, and yeah, I think you might be right about the pain - the typewriter layout looks like it should work much better.
For what it's worth, I'm an unconventional - yet effective - touch-typer, and use my left ring-finger for both the Z and X keys. Typing my ZŻŹs isn't too painful.
I rarely get to come across non-native speakers, good luck : ) Well, note that repositioning "Z" is not just about the pinky. "Z" is present in common Polish digraphs: "cz", "sz", "rz", all of which are easier to type if "Z" is moved to where "Y" normally is.
Type "Szczecin" (my home city) 10 times, and then "Sycyecin" - that's the feeling you'd get on PN-87 :)
Obviously QWERTY isn't a very good keyboard layout to start with. Putting all the letters of the word TYPEWRITER in the top row (to make it easier for the first salesmen to demonstrate the product) wasn't done with everyday user's convenience in mind, English or otherwise.
Hence all these alternatives, such as the most popular Dvorak layout (but also Colemak and plenty others). Which are, however, optimized for English, so a Polish typist wouldn't probably benefit from switching all that much.
> If I recall well, Polish typewriter layout (PN-87) was still available on Windows 95/98.
It's way worse: it's installed by default up to (at least) Windows 7, along with a silent (no feedback!) Left Alt-Shift shortcut that switches the keyboard layout. Press it unknowingly and BAM - suddenly your diacritics don't work anymore and Y/Z are swapped. Annoys the hell out of an Average User.
PS. I'm not saying that the layout was bad - just that there shouldn't be a magic shortcut for a "break my keyboard now!" feature.
I just checked, and it appears PN-87 is included in the default Ubuntu install as "Polish (qwertz)". For whatever reason many distributions include far fewer keyboard layouts than Ubuntu.
Yet another example of why websites shouldn't be able to hijack keys that have meaning outside them (in the browser itself, or in the desktop environment). It still blows my mind that browsers permit this and don't provide an easy option to stop such abusive (and dangerous!) behaviour.
The workaround is typical of web stuff as well: deal with the symptoms one by one while leaving the underlying problem unquestioned.
I feel like that's an old way of thinking. If websites are too grow up and become first class applications, and advancements in Chrome and Firefox are paving that way, we want the browser to become a very thin runtime that doesn't impose any behaviors of its own. It should be mostly transparent to the user that they are in a browser. The fact that different browsers use different shortcuts makes that all the more important, that browser shortcuts need to be invoked in other ways that won't conflict.
Even without web stuff there are many apps, and there is one keyboard and there are going to be key binding conflicts.
Webapps may need low(er) level access to keyboard for legit reasons too. Years ago I was working on webapp that teaches 10-finger typing. It needed to know 'pressed' states of keys like Shift and Alt. There were various browser differences to work around. Luckily the app didn't need to support Polish layout.
So make it opt-in, and highly visible to the user when it happens.
I get a nag screen when videos in the browser go full screen, telling me loud and clear that expected behaviour is changing and telling me how to get control back. When a website overrides keyboard controls, the first I know about it is when I can't scroll properly, or switch to another tab, or go back, or close the window that's yelling at me and making my machine thrash ...
Disruptively changing modes without notification violates fundamental rules of interaction design, affordances and basic security. How is that okay?
When was the last time ANYONE truly used Ctrl-S to save the webpage as HTML? And why would my inability to do it with a keyboard shortcut be a dangerous problem?
I wouldn't -- the number of times I've inadvertently hit C-w rather than C-s (or M-w when I wanted something else), or control-q when I meant to hit control-a, FAR outnumber (by two orders of magnitude) the number of times I've wanted to close windows or exit my application in that manner.
Perhaps it's my windows upbringing, rather than mac, but Ctrl-F4 / alt-F4 are my preferred window/app closers, and I wish dearly I could unmap the other shortcuts sometimes.
What's the relevance of that question? There's no reason it has to be all or nothing. I would harshly criticize any site that overrode ctrl-W but I couldn't care less if they override ctrl-S.
The problem is that the decision is left up to the website.
But I see I'm in the minority here, thinking software should be predictable and leave the user a sense of control, so feel free to disregard my opinion.
I'd be all for browsers blocking the ability of web sites to intercept or repurpose ctrl-W, personally. But I think repurposing ctrl-S is often a good idea.
One might have thought the OP highlighted the inherent problems in making assumptions about the meaning of meta-keys for all of your users, all around the world.
But of course the OP continued to make the same mistake, which I pointed out way up at the beginning of this branch.
Or, as I found on a BBC news page earlier today (and reported via feedback), my middle mouse button on link to open in new tab wasn't -- the page was opening in the present tab.
Don't break user controls.
Seriously. Fucking. Annoying.
The tendency of sites to also force all links to open in a new tab is similarly annoying. I've got the means to choose. Leave it to me.
Another argument for disabling JS pretty much everywhere.
very often without JS you pretty much get an empty HTML
The annoying thing is: if there were a header the browser could send to the server - "JS is turned off" - it'd be trivial to serve a pre-rendered full HTML response.
It's what plenty of e.g. Angular sites do to support the various search engines. Adding one more item to the list of "serve a prenderefndered view if X is true" checks wouldn't do any harm.
What an interesting article. I don't think many people outside of our field realize how obscure some bugs can be, and the lengths needed to diagnose them. Not every bug, of course; not even 95% of bugs. But every now and again, you get something that really tries your problem solving skills... and inevitably it ends up being something small like not checking the state of every meta key.
The much bigger problem is that browsers out there are crap and won't let you re-map your keys as you want them.
How is it that we're well into the 2010's and I still can't get (my own) emacs keybindings in Firefox/Chrome without some silly extension that doesn't work 100%?
I can download uzbl, dwb or any other browser like it and edit my keys as I see fit, for emacs/vim keybinding behavior, without limits.
I don't know about Medium, but I also find that most websites have these hidden shortcuts and you can't even re-map those. Why is there no choice in all this? Browser developers and websites can spend hundreds of thousands of dollars on UX/UI research, but can't figure out that I might want to re-map some keybindings.
> To find room for the extra letters, typewriters needed to dispense with some punctuation, most notably semicolons (comma + backspace + colon), and parentheses (replaced in common use by slashes).
I've seen the slashes-as-parentheses on many (mostly older) documents before, but never knew why. Suddenly this makes so much sense. Unfortunately what makes less sense is official translators still using // for () these days.
Oh nice, an article about my native language on HN's front page.
Currently living in Germany I actually find our approach to special characters really elegant. I was surprised how much different are German (and French) keyboards.
I wonder whether these different layouts can affect for example your programming prowess.
It definitely affects the learning curve. Have a look at the Czech keyboard layout; when I first started learning that language I ended up using the Compose key. Why on Earth would you put diacritics on numerical keys without any kind of logical mapping? At least Polish is 100% logical in this regard (except AltGr-X, but that was unavoidable).
The Russian keyboard layout is similarly annoying as the keys are simply not where you expect them. On most systems you can install a phonetic keyboard driver and kinda roll with it - that is, until you have to use a real Russian keyboard, at which point you have to re-learn from scratch.
Oh, and don't get me started on AZERTY and QWERTZ. What were they thinking?!
The point is that on some layouts you can start typing right away; on other, you have to jump through hoops and get frustrated. Not that we can do anything about it now. Historical reasons.
I find the polish programmer layout very intuitive. National layouts for languages using latin alphabet are often failed customizations of design already not optimal and nightmare for foreigner. Italian - need tilde character? sorry. German - dedicated key for each umlaut and brackets cluttered under 7 - 0. French - AZERTY? really?
While most commentary is (fairly) focused on browser behavior and keyboard hijacking, I'd point out another viewpoint: why the frak does every latin alphabet using nation need its own keyboard layout? Couple of diacritics is hardly a good reason to reshuffle the whole keyboard.
Because typewriters, and therefore keyboard layouts, predate computers. There's no technical reason to not just have composable meta-keys, excepting maybe the pure number of existent diacritics [0].
In fact, on the German keyboard, the circumflex (ˆ), acute accent (´), and grave accent (`) keys all compose with the next entered character. (That is, á is entered by pressing ´, then pressing a.)
Windows also offers an "international" keyboard mode which allows composition in a way similar to the German keyboard. [1]
> Because typewriters, and therefore keyboard layouts, predate computers
Even early US computers (and typewriters before them) had relatively varied keyboard layouts, but somehow[1] they still managed to converge into the standard 104 key layout that we have today in the early 90s (and that is a quarter of century ago). What we have missed is the extension of that convergence into international community.
> There's no technical reason to not just have composable meta-keys, excepting maybe the pure number of existent diacritics [0].
> In fact, on the German keyboard, the circumflex (ˆ), acute accent (´), and grave accent (`) keys all compose with the next entered character. (That is, á is entered by pressing ´, then pressing a.)
Dead keys are fairly good solution. Indeed I counted 19 dead-key diacritics on my countrys official standard keyboard (which almost nobody uses).
In Polish cz, rz, dz, and sz are very common, like sh and ch in English. Look at your US style keyboard and notice when typing ch and sh it is a L followed by R hand press. Now look what happens when you want to enter the common Polish cz, dz, sz, or rz. They are both L hand. So that's why Y and Z are better swapped for Polish language. L and Ł are better to be two separate keys because often there is only one modifier key for the letters with tails and it is on the right near the L key.
I'm sure they don't, but it's hard to overcome tradition. I imagine there was no real reason to share layouts across countries in the 1800s when a lot of this stuff was hashed out.
(I'm half joking, half serious - I grew up with a qwertz DE nodeadkey layout which certainly doesn't look sane from the outside either and exclusively use the US one now)
I use regularly English, German and Romanian. I find it easier to learn using the two extra standard layouts (not the programmer version) and change between them by ALT-SHIFT than pressing ALT-X for every diacritic. The WPM count falls drastically using the ALT key all the time.
Reading this reminded me of how incredibly annoying it is that new OS'es don't always underline the shortcut key. It's maddening! I can't seem to get it to work in Unity; auto-mnemonic true or false makes no difference.
I first learned about this issue while working on Primrose.
Things get really hairy in the browser when you start talking about JavaScript, the keyboard, and international support.
For example, there is no way to know what keyboard layout a user is using. With Primrose, I guess based on the user's default language, but even that isn't perfect as a lot of not-US English speakers just show up as "en", with no further locale description, so I also provide a select list with all of the available choices.
It's very difficult to know with certainty what character a user is intending to type. KeyCode 51 with no modifier keys is "3" on most keyboards, except French, where it is "#" (they essentially swap the casing of the number row).
The number pad numbers send different keycodes than the number row numbers, but the number pad arrows (if you turn off the numlock) send the same keycodes as the arrow keys.
In languages with deadkey support for diacritics (such as French and German), the deadkey keyCode isn't sent until the second key is typed. Then, they are sent in rapid succession.
There is absolutely no way to know what is going on with IMEs.
And there is no reliable way to interact with the soft keyboard on mobile devices. Some versions of soft keyboards don't send the arrow key keyCodes. There is no standardization of what keys should be available, so you can't guarantee that your user will easily be able to type your shortcuts (I know of only one keyboard on Android that even has CTRL or ALT). And it's nearly impossible to know how much space the soft keyboard is going to take up on the screen (you can figure it out on Android, eventually. It's impossible on iOS.).
So, you have one of two choices, if you're trying to implement any sort of browser-based application that involves heavy use of the keyboard.
Option 1: You can either create a hidden, surrogate text area in which the user actually types, unbeknownst to them, and run a sync process between the content they type and the content you display. This has several problems: you have to wait for keyUp to activate shortcut commands. The sync process can be costly (especially in the context for which Primrose exists: WebVR) and it is difficult to keep the cursor view in sync when dealing with mouse/touch interactions. Oh, speaking of pointer actions, you have to make sure your surrogate text area is positioned exactly under the displayed text field, with the text appearing the same apparent size as the displayed text, because when it gains focus the browser will scroll the view to it.
But it will work, except for certain use cases. It won't work well on mobile, and it won't play nicely with WebVR (which is the entire point of Primrose, anyway), especially for Asian users using an IME.
So Option 1 isn't a good option.
Option 2: completely reimplement the key input stack, i.e. create all the keyboards and soft keyboards and IMEs your users will ever need. Completely ignore what the OS and the browser tell you, take only the raw keyCodes, and reconstruct what is happening. It's a lot of work, a lot to debug, but at least there is a path to actually solve every problem.
Fourth. While Ukraine is a bilingual country, it still much bigger than former Yugoslavia. Most people there consider it their native language and a majority know it. So if you are strongly biased for a small number you'll get 30 million speakers, if you are biased for a big number it might be 50 million.
And on top of that you must use the same criterion for the S-C language, not counting Slovenians, Albanians, Macedonians, etc who know the language but don't use it much anymore.
That one of the developers at Medium could run into such a glowing example of one of the many reasons it's nasty to override browser behaviour, and take the lesson from it that oh hey, we just need to make our override logic more complicated... the blindness and idiocy and sheer bloodymindedness of this response I just can't even.
Medium: YOU'RE DOING IT WRONG.