On Thu, 21 Sep 2006, Web APIs Issue Tracker wrote:
ISSUE-88: AJAX (and serious use of javascript in general) b0rks
history, bookmarks, etc
http://www.w3.org/2005/06/tracker/webapi/issues/88
Raised by: Charles Mccathienevile
On product: All
Manipulating the DOM to update pages generally means that it is
impossible to bookmark them, retrieve them in history, link to
them, etc, in any but their initial state.
This is a problem in common with frames and sites that hide
everything by pushing all interaction via POST requests. Although
Ajax generally provides much better services, we are also breaking
one of the main features of the web - that if I see something
cool, I can send someone else there.
I suspect that we should look at two approaches - one trying to
provide guidance to authors (I know that Dave R's JS-heavy slide
system does solve this problem - perhaps he could be convinced to
write more generally on how to deal with this issue), and the
other to talk to user agent developers about what can be done in
this regard.
(Raising this issue completes ACTION-208)
Slidy is a web application that presents a sequence of slides,
where each slide is marked up as a div element with a class value
of "slide" and the set of slides are contained in a single HTML
document. One challenge was to allow users to bookmark a given
slide. This is addressed through the URI fragment identifier using
an application specific syntax: #(3) denotes the third slide.
When the slide deck is first loaded, the onload event is used
to initialize the list of slides, and to check which slide to
show, based upon the fragment identifier, as determined by the
value of location.href.
When the user moves to a different slide, location.href is
updated to indicate the appropriate fragment identifier for
the current slide. This is necessary in order for the browser's
set bookmark mechanism to reference that slide. Sadly, some browsers
(e.g. Konqueror) always reload the document whenever location.href
is updated. The script therefore checks which browser is being
used to avoid this happening (it can cause a significant delay
in advancing to the next slide).
Users are generally familiar with the back and forward actions
that browsers support for regular web pages. Unfortunately,
this expectation is dashed when it comes to virtual pages
presented by Web applications like Slidy, as browsers vary
wildly in how they treat the history when location.href is
updated. Some browsers push the previous value whilst others
don't.
Ideally, updating location.href to a different value should
push the previous value to the history. Invoking the back
or forward actions should then act on this history. For this
to work smoothly the document shouldn't be reloaded if the
URI is unchanged except for the fragment identifier. Reloading
the document discards the internal state of the web application
and forces a complete re-initialization.
That raises the question of how the script determines that
location.href has changed, triggering the corresponding change
in the application's state (for Slidy, this means moving to the
corresponding slide). The onload event is adequate for this purpose,
and global variables can be used to distinguish the first time from
subsequent occasions that the onload event handler is invoked.
If the above semantic for window.location.href is widely adopted,
then applications will be free to utilize the fragment identifier
to support user expectations for both history and bookmarks.
Dave Raggett <[EMAIL PROTECTED]> W3C lead for multimodal interaction
http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
