HTML and CSS Reference
In-Depth Information
Effect on Browser Bookmarks
The history-tracking problem described in the preceding section also has an undue effect on bookmarks.
Suppose a user is on slide 3, which displays information about a spanner. The user may want to re-read the
same information later and so adds a bookmark to this page with the impression that slide 3 has been
bookmarked. However, because there are no unique URLs for different slides, the browser adds a
bookmark to the base URL (
http://localhost:1065/Ajaxhome
). The next time the user accesses this
bookmark, the first slide is shown instead of the third because the server sends the first slide from the
database for the URL.
Effect on Search Engine Listings
The Slide Show application also suffers from one drawback that no webmaster wants to have in their
applications. Because there is just one URL for all the slides being displayed, search engines capture and
list only this URL. If each slide was assigned its own unique URL (as in the non-Ajax version you developed
earlier), then search engines could list all the slides in their databases. To allow users to search for and find
unique information, you need a unique URL for each independent piece of information—in this case,
each individual slide. The Ajax version of the Slide Show application in its current form violates this
recommendation, affecting the application's search engine listings.
The Solution
Now that you understand the problems faced by Ajax-driven applications in terms of tracking history,
bookmarks, and search engine listings, let's discuss the possible solutions. The basic cause of all the
problem areas discussed earlier is that there are no unique URLs to identify independent pieces of
content. To solve these issues, you need to create unique URLs for each such piece of information. As far as
Ajax applications are concerned, there are two ways to generate such URLs:
• Using hash fragment in the URLs
• Using the new HTML5 History API
Using Hash Fragment in URLs
This technique involves generating URLs by adding a hash fragment at the end of the base URL. For
example, consider the following URL:
http://localhost/slideshow.aspx#slideid=3
In this address, a slide ID is appended after the base URL using
#
. The browser ignores all information
after
#
and doesn't send a separate request to the server. However, this is still a unique URL. You can
append any number of key-value pairs in the
#
fragment, just like a query string; the only restriction is the
size limit of the query string. Once you've created a hash-fragmented URL, you can navigate to it using
standard navigation techniques (clicking a hyperlink or programmatically calling
window.location.href
,
for example). You then need to write JavaScript code to read the hash fragment data and display the page
content accordingly.
Although hash-fragmented URLs appear to solve the problem, they introduce problems of their own:
• Processing hash fragments often becomes too complex as the amount of data you
want to pass increases. Some JavaScript libraries do the job for you, but over all the
code tends to become tricky with hash-fragmented URLs.
