Re: ISSUE-88: AJAX (and serious use of javascript in general) b0rks history, bookmarks, etc

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 <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

Received on Monday, 2 October 2006 12:37:43 UTC