Re: No JavaScript for previous page and print screen

> The "next" link URLs are hard coded to direct the user to the next file.
> However, instead of hard coding URLs into the "prev" links, we have used
> JavaScript (history.back()) hoping that it would help us in the future from

These are not suitable for resources that form part of the world wide web,
as the incoming web link could be from any resource at all or hand keyed,
so will not, in general be to the logicall previous document.

In my view, pages that replace standard browser controls with in content,
but equivalent, controls are only suitable for use within organisations
that are have tight control of the browsers in use and the security 
policies on those browsers, i.e. that they are not used on the internet.
On the internet, many will be using browsers you don't expect - the control
disabling functions are proprietory functions and make asumptions about the
browser user interfaces - or have security policies that are incompatible -
I always have scripting warnings on, and am irritated by sites that produce
lots of warnings or force me to make a judgement about them and then reload
the page accepting the script.

Also, in my view replacing standard controls should only be considered for
applications that users will use on an almost daily basis, and even then
one should ask oneself what ones real motives are.

> re-coding all the "prev" links if we had to insert an additional page in the
> middle somewhere.  We also used JavaScript for printing the current screen

For the next and previous links (which would be tagged with rel="next",
(some browsers may then display logical next and previous buttons in their
tool bars), you should probably use URLs that are something like 
<current-URL>-next and <current-URL>-previous, and have the server return
a status 302 (temporary) redirect to the actual previous or following
page.  That minimises the server load.

Received on Thursday, 22 May 2003 02:40:40 UTC