Increasingly, sites are doing client-side rendering at page load time, which is breaking the (useful) functionality of being able to have a #hash on a URL that auto-scrolls the page to make some element visible after page-load.
A perfect example of this problem is that most #hash URLs (as far as scrolling) are broken on gist.github and github when viewed in recent Firefox. https://gist.github.com/getify/5558974 I am proposing that the browser throw a JS event right before it's about to try an auto-scroll to an element with the #id of the #hash in the URL (during a page's initial loading), called for instance "autoscroll". The purpose of this event is to simplify how a web app can detect and respond to a URL having a #hash on it that would normally create a scrolling behavior, even if the element isn't yet rendered for the window to scroll to. That gist shows how you could listen for the event, and store for later use which target-ID was going to be scrolled to, and manually scroll to it at a later time. If you have an app that does client-side rendering where it can break auto-scrolling, but you want it to work properly, you can of course manually inspect the URL for a #hash at any point, but it's a bit awkward, especially if you are already relying entirely on event-driven architecture in the app, and you want to just detect and respond to events. This "autoscroll" event will normalize that handling. Notice the polyfill code in the above gist shows that you can obviously detect it yourself, but it's awkward, and would be nice if it were just built-in. Additionally, having it be a built-in event would allow an app to prevent the browser from doing unwanted auto-scrolling in a very simple and natural way, by just trapping the event and calling `preventDefault()`. Currently, there's not really a clean way to accomplish that, if you needed to. --Kyle
