>I've seen some sites overriding context menus to provide their own copy/paste commands (for unknown reasons, probably to change the look). In doing so, they remove all the options browser puts in there.
Of course, and you've probably seen much worse than that. Incompetent web designers are plentiful, but the capabilities of a web site are not limited to "broken sites made by incompetent designers".
>If HN wanted to use context menus for some app-specific reason, all of those options would be wiped out (at least for affected elements) because the app would be in direct conflict with the browser.
If HN wanted to do something incredibly stupid, they could do something incredibly stupid. Right. I'm not sure what the issue is there. If they wanted to not do something incredibly stupid, that is also an option. Why judge only on the worst possible scenario and assume every website is designed to be as broken and shitty as possible?
>Touch events are often another casualty -- sometimes they are commands to the OS (swipe to change active desktop), sometimes to the browser (pinch to zoom), sometimes to the app (drag to drag around a map, or maybe pinch to zoom?).
This applies equally to apps vs web, and isn't even specific to phones.
>Additional layers always introduce problems and cause things at the end of the chain to have worse UX or adapt by using lowest common denominator
That statement is false, and not relevant. The browser is no more an "additional layer" than an app is. The same number of layers in both cases.
> If HN wanted to do something incredibly stupid, they could do something incredibly stupid. Right. I'm not sure what the issue is there. If they wanted to not do something incredibly stupid, that is also an option. Why judge only on the worst possible scenario and assume every website is designed to be as broken and shitty as possible?
But context menu is a useful concept (sometimes). It _would_ be nice if it could be used when it is called for. The problem is that it is impossible (I think) to use context menu or _any other right click action_ you could think of without breaking browser functionality. It would be like you said, incredibly stupid.
Thus web apps effectively lose one whole mouse button, thus reducing available input bandwidth.
Another example of lost input is lack of system-global shortcuts. A web app in my knowledge can't have them. I listen to music while I work and I tend to switch tracks or pause them once in a while. So when I listen to youtube playlists, I have to go back to the browser, open the playing tab and do it there. (and you never know if the video currently playing is SFW :))
> That statement is false, and not relevant. The browser is no more an "additional layer" than an app is. The same number of layers in both cases.
The browser is a layer, and the native-app is a layer, except to get to web-app, you need to go through the browser first and a native-app sits at the same level as the browser (so a portion of input capabilities is not used up for the browser itself).
>But context menu is a useful concept (sometimes).
Of course. Which is why you would use it only where it is useful, not just hijacking a particular input event globally.
>Thus web apps effectively lose one whole mouse button, thus reducing available input bandwidth.
No, you can use right click all you want, and it need not interfere with the browser's use of right click. Also, very few people use a mouse on their phone, so this does seem like a bit of a stretch.
>Another example of lost input is lack of system-global shortcuts. A web app in my knowledge can't have them.
Right. There are a few other things like this that web apps can't do. And apps that people would want this sort of interface for should not be web apps. But as I said originally, virtually all the apps people use are not of that nature (and those that are almost always are apps that came with the phone), they are just websites turned into clunky, awkward apps for no reason.
>except to get to web-app, you need to go through the browser first
Of course, and you've probably seen much worse than that. Incompetent web designers are plentiful, but the capabilities of a web site are not limited to "broken sites made by incompetent designers".
>If HN wanted to use context menus for some app-specific reason, all of those options would be wiped out (at least for affected elements) because the app would be in direct conflict with the browser.
If HN wanted to do something incredibly stupid, they could do something incredibly stupid. Right. I'm not sure what the issue is there. If they wanted to not do something incredibly stupid, that is also an option. Why judge only on the worst possible scenario and assume every website is designed to be as broken and shitty as possible?
>Touch events are often another casualty -- sometimes they are commands to the OS (swipe to change active desktop), sometimes to the browser (pinch to zoom), sometimes to the app (drag to drag around a map, or maybe pinch to zoom?).
This applies equally to apps vs web, and isn't even specific to phones.
>Additional layers always introduce problems and cause things at the end of the chain to have worse UX or adapt by using lowest common denominator
That statement is false, and not relevant. The browser is no more an "additional layer" than an app is. The same number of layers in both cases.