[whatwg] suggestin a minor addion to the DOM
Ian Hickson
ian at hixie.ch
Thu Aug 30 10:54:23 PDT 2012
On Thu, 28 Jun 2012, Andri Sævar Sigríksson wrote:
>
> suggestion
>
> Boolean value
>
> implemented as Window.nobackspace or Navigator.nobackspace
>
> if set to true the browser would not accept the key press on backspace
> as a signal to go to the previous page
>
> yes i know there is a other way to do this but i find it unelegant
On Thu, 28 Jun 2012, Bjoern Hoehrmann wrote:
>
> Why would users want that?
On Thu, 28 Jun 2012, Chaals McCathieNevile wrote:
>
> Generally it isn't a very nice thing for users not to go back. It's a
> pretty fundamental part of the way we navigate the web. Redirecting the
> back button somewhere else because of a strange forward navigation path
> might happen, but breaking the general expectation isn't usually a good
> idea.
>
> Also, the fact that we have an inelegant way of doing something isn't
> necessarily an argument to make it easier. If it's a really common thing
> to do, then it makes sense to simplify it. But if it is a weird edge
> case, then duplicating stuff is a good way to let bugs creep into
> implementations, which come at the expense of doing something more
> useful...
On Thu, 28 Jun 2012, Tab Atkins Jr. wrote:
>
> You may be misreading this - it's about turning off the "backspace means
> go back in history" functionality that some browsers have in some
> circumstances. It's not trying to shut down back navigation generally.
>
> I can easily see an editting-heavy page wanting to turn off this
> behavior, as when I was still a FF user, I'd occasionally get accidental
> navigations because I didn't notice that an input or textarea had lost
> focus.
On Thu, 28 Jun 2012, Chaals McCathieNevile wrote:
>
> Ah. In that case I can see the use case. But I don't think this is such
> an elegant approach either, because the underlying problem is not just a
> specific key but the general behaviour of the browser when you are
> dealing with interactive components (editing is one). This is related to
> the use cases for the aria role "application"...
I haven't added this, but I agree that it's an issue. Really what is
needed is more a "keyboard capture" mode where normal keyboard shortcuts
get disabled so that the application can handle them. However, it's not
clear exactly which you would want. Sometimes you might e.g. want
left/up/right/down to no longer scroll the page, but other times you might
still want it to scroll an overflowing div. You might want the space bar
to not scroll down but instead to fire a weapon in a game, but if the app
scrolls (e.g. as GMail does) maybe you still want it to page down.
I don't know what a good solution is. The current solution is to just
catch the keystrokes you care about and cancel them... that might just be
the way to go for now.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list