[whatwg] anchor(jump) DOM Event proposal

[Loune]

Ric Hardacre wrote:
> sounds good, and logical when compared with anchor and button onclick 
> for example.
>
> to clarify, where would the event be attached by default? document or 
> window? i.e. would i
I'd say it would be attached to the same places as the load event.

I've had a look at the "Session history and navigation" state spec and 
if I'm interpreting it correctly, it only solves part of the problem.

Using state objects you would:
1) Implement the popstate event
2) use the window.pushState(stateobject) to push the state into the 
"state stack?"
3) When user navigates back, popstate event fires with the state object

 From the terminology, I gather that once you popped the state, you 
don't have the state in your history anymore? That means after you 
navigate back, you can't go forwards again. The state spec also leaves 
room for a URI to be associated with the state. But it begs the question 
of how will the URI be correlated to the state DOMObject in way that the 
URI can restore the state, even if the URI is posted to a web page, or 
sent via email to a friend.

However, The good thing about the state spec is that it was created with 
the explicit intention of solving the AJAX problem, where as the 
onanchor spec is more of a piggy back on to an existing feature. Indeed, 
I came up with this spec when I set out to solve the AJAX problem with 
the current range of browsers, but fell short, because I couldn't find 
an event that would be reliably triggered when the anchor URL changes.

I think the two specs, onanchor/state can be reconciled. The traditional 
anchor jumping could be made a behaviour of a modified state spec. Each 
jump will be regarded as a new state of page in the session history. It 
will however need some modifications for it to be able to perform like 
it is on current browsers (going forward, URL change, scrolling).

cheers,

-l