Re: [whatwg] anchor(jump) DOM Event proposal
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
Re: [whatwg] anchor(jump) DOM Event proposal
Flow of events:
- When the page is loaded, and an anchor event listener exists, the
anchor event will be fired after the load event. If there is no anchor
in the URL, the event.anchorName property will be an empty string.
- When an anchor link is clicked, the anchor event listener (if exists)
will be fired
- The event handler can get the name of the anchor via event.anchorName
(which will contain the string after the hash)
- If the return value from the handler is true, the traditional form of
operation (the jumping to the anchor) will occur next; otherwise, that
step is skipped.
- The UA should act as if the navigation has gone forward a page (add
history, etc).
- If the user navigates back and the previous page happens to be the
same page but a different anchor, the anchor event again will be fired
as if the previous anchor was freshly navigated to. The same logic
applies to navigating forward.
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
function myonAnchor( e )
{
if( e.anchorName )
switch( e.anchorName )
{
...
default:
return true;
}
}
document.onAnchor = myonAnchor;
---
Ric Hardacre
http://www.cyclomedia.co.uk/
Re: [whatwg] anchor(jump) DOM Event proposal
On Tue, 28 Feb 2006 14:09:01 +0200, Loune [EMAIL PROTECTED] wrote: Hi, ... What this achieves: With the anchor event handling implemented in a webpage, the page can now react to backwards and forwards events of the browser, without having to reload the whole page. The user can also bookmark a specific state of the page, as specified in the URL. Comments appreciated, Yes, great suggestion Loune, as Alexey said. I've been following the WHATWG mailing list for quite some time now and, as far as I remember, the AJAX problem has already been discussed. Even the specification (if I am not mistaking) provides the means of tackling/solving the problem, see Session history and navigation [1]. Yet, as I see it, your suggestion is more elegant and easier to use. The state objects defined by WA 1.0 are very good, but they might be way too much for simple usage. [1] http://whatwg.org/specs/web-apps/current-work/#scs-session -- http://www.robodesign.ro ROBO Design - We bring you the future
[whatwg] anchor(jump) DOM Event proposal
Hi,
I don't know if this has been addressed or not, since I only briefly
scanned the spec. Hopefully, I didn't write this for nothing :)
This relates to the handling of anchors in URLs:
A common argument or complaint against AJAX is that it renders the back
and forward buttons useless and thereby interrupting the normal flow of
browsing. It is also impossible to bookmark the state of the page [due
to the URL remaining the same]. Normally, navigating to a new URL will
result in the browser performing a new request to the server, but there
is one exception to that - which is invoking an anchor via # suffix.
Traditionally, the suffixes are used to jump to the location which the
invisible anchor is located.
My proposal is to extend anchoring into a scriptable feature with the
addition of the anchor DOM Event. The anchor event will be fired every
time the page URL stays the same but the anchor suffix of the URL
changes. This basically includes:
- Back and Forward navigation of anchors
- Manually typing a URL/Loading from a bookmark
This is not unlike typical GET query strings where the portion after ?
are variables passed to the same script on the server, with the main
difference here being that this acts as a client-side query string. The
anchor event will be used to perform an action by the JS on the same page.
What the event interface could look like:
interface AnchorEvent : Event {
readonly attribute DOMString anchorName;
void initAnchorEvent(in DOMString typeArg,
in boolean canBubbleArg,
in boolean cancelableArg,
in DOMString anchorNameArg);
void initAnchorEventNS(in DOMString namespaceURI,
in DOMString typeArg,
in boolean canBubbleArg,
in boolean cancelableArg,
in DOMString anchorNameArg);
};
Flow of events:
- When the page is loaded, and an anchor event listener exists, the
anchor event will be fired after the load event. If there is no anchor
in the URL, the event.anchorName property will be an empty string.
- When an anchor link is clicked, the anchor event listener (if exists)
will be fired
- The event handler can get the name of the anchor via event.anchorName
(which will contain the string after the hash)
- If the return value from the handler is true, the traditional form of
operation (the jumping to the anchor) will occur next; otherwise, that
step is skipped.
- The UA should act as if the navigation has gone forward a page (add
history, etc).
- If the user navigates back and the previous page happens to be the
same page but a different anchor, the anchor event again will be fired
as if the previous anchor was freshly navigated to. The same logic
applies to navigating forward.
What this achieves:
With the anchor event handling implemented in a webpage, the page can
now react to backwards and forwards events of the browser, without
having to reload the whole page. The user can also bookmark a specific
state of the page, as specified in the URL.
Comments appreciated,
cheers
-l
