Hacker News Reader

Comment by qewrffewqwfqew | Hacker News Reader

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.

View on HN

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.

Split the web. If you want an applications platform with HTTP transport, build one. If you want a documents platform, build that as well.

Split out commerce and media while you're at it.

The present model's working increasingly poorly for me.

> It should be mostly transparent to the user that they are in a browser.

Even if the browser is providing your entire desktop experience, you should be able to switch applications or close them in a predictable way.

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?

It's ahem dangerous?

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?

Would you be so dismissive if the overridden key were Ctrl-W?

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.

Reply on news.ycombinator.com