Blogger is notorious for "reimplementing the web experience". Just try opening a Blogger page on an iOS device. You'll get an empty page, then spinning gears, then after a while the page will finally land. Then you'll have a page which won't scroll properly. Because someone just had to reimplement scrolling. Better.
Let's take the horrible Onswipe themes as another example. They not only break functionality and make the page slower, but also break zooming in and show buttons that pretend to be iOS buttons, but aren't.
I could rant about this for hours. It's all the same basic problem: people trying to redefine/hijack basic browsing functionality. I interpret this as extreme hubris ("I know how to design this better!") or arrogance ("this is how you will view my site, period!").
The advice of this article is good, but I don't think it should be up to individual website authors to behave well. Ideally, there ought to be a standardized javascript API for binding control keys. Then the browser could prohibit rebinding if desired (while giving feedback to the webapp as to whether rebinding was allowed), and provide an accompanying UI for the user to see which controls are enabled/disabled, to whitelist or blacklist websites, and so on.
One of the dumbest I've run into is to jack ctrl-f and send it to a site search box. If I use ctrl-f, it's because I meant to do an entirely different thing, or by accident. In no case is it because I want to search your article archives.
If by nodding, you mean nodding out. For some reason, they've specially crippled the '/' search, and removed the configuration variable to make it identical to ctrl-f (next/last arrows mostly.)
If you happen to read this and are irritated by the same thing: I was saved by "Findbar Tweak." New essential plugin for me.
I've no objection to configurability, but I don't want slash to behave the same as ctrl-f. In particular, when my /-search matches part of a link, hitting return follows the link. Ctrl-f searches for next, which functionality I already have access to with ctrl-g.
Edited to add - how can you stand the lack of next/last arrows in vim?
Far worse are websites like Battle.net that hijack the onpaste events to prevent pasting passwords. Hijacking keyboard shortcuts may cause inconveniences but prohibiting password pasting is a security flaw.
Preventing users from pasting their passwords is quite irritating. I don't even understand the idea behind it. Most likely some developer saw a non-technical user copying/pasting from a plain-text password file, and "had a great idea" to discourage that kind of behavior.
To get around sites that do this, I inspect the HTML and add my password via the value="" attribute on the input element.
KeePass has a great autotype feature that perfectly bypasses that by simulating real keyboard input.
When it comes to anti-clipboard, I really hate sites that make you enter your email address twice (Which is retarded anyway; WHY THE FUCK would I not know/check what I am typing?; it's a cleartext field, you might as well have 2 fields for everything up to first name FFS...), then stop you copying emailfield1 to emailfield2. Fortunately, most still let me click and drag from 1 to 2.
What I really hate is accounting ledgers that make me enter things it two places. Geeeze.
The reason email is special is because if that's wrong there's often no good way to fix it (and certainly no way to notify you). Whether that's sufficient motivation is a matter of judgement, but it's clearly different than first name.
A lot of people that use password managers don't know their passwords (I only know a few of mine). Maybe calling it a flaw is too severe, but it isn't doing those folks any good.
I'm curious as to how that would affect a password manager? I was always under the impression that they would directly manipulate the DOM (or perhaps alter the outgoing request)?
It could be that some people use password managers that require pasting. (though many don't) It could lead to people using passwords that are easier to remember if their password manager doesn't work.
Hm, this set me wondering how much risk there is passing the passwords through the copy-paste mechanism itself. Probably not terribly much more than passing through the keyboard and IO subsystems, though. Still, I know with X selection buffers, when data is requested the application it's requested from can run arbitrary code to generate (or check!) it and is passed the window-id requesting[0]. It seems like a password manager could make use of this to implement an ACL and lock things down tighter - do any do this?
I guess that is something of a double-edged sword then. You might force someone to use a weaker password, but then hopefully they wouldn't be keeping it in a place where they could simply copy/paste it. This really starts to delve into the whole "security is a gradient with tradeoffs" situation.
I'm assuming in this scenario that they would be keeping passwords in a plaintext file. If they kept passwords in an encrypted file, wouldn't they need to decrypt it? Wouldn't you presumably have a strong password to decrypt it? Where is that kept? How strong must one's password be when that password is keeping other passwords secure? If they can remember that password, why can they not remember others?
Anything that makes passwords harder to do right without simultaneously blocking some attack worth caring about is bad for security. Two of the biggest problems in security are that it's hard to do things the right way and that people just don't understand it.
Whether you want to call it a "security flaw" is not obviously an important question.
KeePass can use a virtual keyboard to type into stupidly designed fields (no need for DOM), but not all of them. Many use the clipboard to some degree.
Yahoo Mail hijacked the down arrow: Looking in the preview pain, press down arrow to scroll... and you jump to a new mail. Very, very jarring and frustrating. I recall they also hijacked a bunch of other keys, none of which made much sense, which is sad... mostly because it shows that they don't use their own products enough to see how this can affect users.
Google+ appears to do the same thing with C-PgUp and C-PgDown; if I had wanted those keys to stop working properly, I would have used some ass-backwards browser like IE. If I've got a Google+ post open and I'm scrolling brisking through tabs, it's like hitting a brick wall.
Well, I don't think it's a bad idea to have specific shortcuts which disable the normal behaviour of a browser, and improve the UX of a website. If they exists:
* they should be explicitly enabled (i.e. RES for reddit)
* you should be notified if they are changing browser behaviour, and an option to disable shall be provided.
In practice the only way users are going to discover these "features" is by accident. How would someone be notified the behaviour is changing? The About page nobody reads?
The problem is not that sites are choosing to override browser shortcuts, but that they can do so at all. The browser should not allow its shortcuts to be overridden. In Vimperator you have to enter a pass-through mode, so this kind of overlap never happens.
I agree. But unfortunately many of the browser creators want to support full-fledged apps within a browser, which in their minds necessitates the rebinding of core shortcuts. A great example is command/control-s in Google Drive Documents.
That's not a conflict, if you're using vimperator. In one mode, you pass whatever. In the other, you pass nothing. The only conflict would be around a site wanting to bind escape...
Is this the same Blogger that requires JavaScript to view plain text? Or maybe I'm getting it confused with blogspot, I can never keep them all straight. In any case, I don't think it's a coincidence . . .
This speaks to a broader issue with trying to keep every hotkey at the top level when you have multiple, nested containers. There is a fantastic solution to this: have a leader key that says "I am talking to my browser", where one of the sub-commands is "pass a literal leader key through". This is the way screen/tmux and ratpoison handle key bindings, and it means there is literally zero chance of a collision that I can't trivially resolve by slightly modifying my interaction.
Ever tried the "Metro" version of Outlook Web Access, the one used with Office 365? It hijacks "Ctrl/Command + R" as a shortcut to "Reply". How oblivious is this?
This is just the result of transitioning HTML to an applications framework. Now the application you use to view articles is not your browser, but Blogger (or WP etc).
Yeah this is big to me. Even for system utilities. I use an OS X volume booster called "Boom"(http://www.globaldelight.com/boom/) (which is nonfree but worth the $7) and it, by default, hijacks cmd + +/- for zooming in chrome. Please don't do this!
This is an inherent problem with web apps, since they're an app within an app. There are two different contexts fighting each other. Who's to say that Ctrl+S should save the app state or the page? Whatever we choose as the default, the non-default scenario would feel awkward when we need it.
I can think of two ways to solve this: (1) decouple apps from the browser frame or (2) use a special modifier key for app shortcuts (perhaps re-use the Windows key, e.g. Win+Ctrl+S).
Yeah, that's pretty messy. As an Opera user I had no idea that other browsers used Ctrl or Alt for access keys. That's just a recipe for disaster. Opera's Shift+Esc combo guaranteed no clashes with browser shortcuts, but it was really kludgy to use.
"An exception may be if your site provides specific functionality such as in a drawing application. Even in this case it is best to provide shortcuts as an option the user has to turn on rather than one that is on by default."
Yeah. From a usability point of view, I think it's important to hijack some shortcuts, but only those who are not commonly used for such as the one mentioned in the article. I would also argue that this behaviour of blogger is not what users expect, hence it is not a bad behaviour. Wasn't there a pair of shortcuts commomly used for this purpose, Ctrl-K / Ctrl-J if i'm not mistaken?
So fucking true. Obnoxious javascript masturbation pattern #47,601 that will make me blacklist scripts from your site. Same for single-key shortcuts (I'm looking at you there, JIRA...).
Let's take the horrible Onswipe themes as another example. They not only break functionality and make the page slower, but also break zooming in and show buttons that pretend to be iOS buttons, but aren't.
I could rant about this for hours. It's all the same basic problem: people trying to redefine/hijack basic browsing functionality. I interpret this as extreme hubris ("I know how to design this better!") or arrogance ("this is how you will view my site, period!").