Re: [whatwg] Proposing: "autoscroll" event

>> There have been times this automatic behavior has been quite annoying
>> because of accidential ID/hash overlap.
> 
> Please explain how a document subresource can be “accidentally”
> referred to by a URL be “accidental”. I do not understand it.

In my case, I ran across this once (not too long ago) where I unintentionally had chosen a URL #hash value that turned out to collide with a DOM element being added to some pages via a third-party widget. The weird somewhat-randomish scrolling was difficult to track down, and when I did, it made me wish I could have just suppressed the problem by canceling the scroll in those cases.



>> You're using a hash to store information that is used by JS.  You also
>> use ids on your page.  These can collide unintentionally, causing a
>> scroll on page load.
> 
> The simplest solution (by far) would be to stop storing “information
> that is used by JS” in a hash. Even Internet Explorer has pushState()
> these days: <http://caniuse.com/history>.

This isn't really about older browsers, per-se. Sure, some people still support IE <= 8 (usually by using a shim like History.js which automatically switches back to the #hash method in older browsers). But if those browsers are currently "broken" (in their inability to cancel scrolling as a result of id/hash collision) then the new proposed event won't be in those older browsers and thus won't fix them. So, mentioning browser support is kind of a misdirected argument.

You *can* conviently just say that all apps should switch to using fully semantic server-renderable URLs across the board, and thus the stuff they store in their History state URLs are canonical URLs that will work fine from the server. However, not all apps have been able to 100% make that jump yet.

I've worked on a couple that were hybrid, using some of the new semantic URLs but still representing some sub/intermediate navigation states (like in a shopping cart, for instance) in the #hash of the URL (that is, rendereable ONLY on the client-side thus there's no server-side semantic URL to choose), even if they still stick that #hash URL into pushState History for backward/forward nav.

Also, bookmarkability and sharability (to these non-server-renderable states) basically sometimes prefers still using #hash'd URLs.

The point is, it's not terribly helpful for you to just redirect the conversation to an entirely orthagonal (and somewhat more complicated) topic of adoption of History API and semantic URLs, especially since this (auto-scroll cancelation) is only one part of the main proposal.

We're kind of off on that tangent here and it's probably not helpful to belabor it more. I just mentioned as a side-note really earlier in the thread that I've had cases where a cancelable event would have been much easier.

Received on Tuesday, 14 May 2013 23:31:45 UTC