Auto-refresh

A.10.1. currently reads:

 For auto-refreshing or timed response pages, provide a second copy of
 the page where refresh only happens after a link has been selected
 (until user agents provide this ability themselves). [Priority 1]

The message we want to convey is that there are two different uses of
the refresh command that correspond to two different problem, with
different priorities:

First kind:

  <META HTTP-EQUIV="refresh" CONTENT="5; http://www.acme.com/newpage">
  <BODY> If your browser supports Refresh, you'll be transported to 
         our <A HREF=http://www.acme.com/newpage>new site</A>
         in 5 seconds, otherwise, select the link manually.

this is an auto-refresh page that acts as a redirect, that is, as a
way to transport the user to a replacement page. The guidelines is:
use a real redirect at the server level, do no waste users time
reading an obsolete page that disappears suddenly (strong serial
medium annoyance) and can mess up the browser history: P2

Second kind:
 
  <META HTTP-EQUIV="refresh" CONTENT="60">
  <BODY> Real info, with images, tables, like Wall St

This is periodic auto-refresh page, kind of poor's man server-push,
used to replace a real page, with real information, with an updated
one. Here the message is: don't do it; you, the author, cannot guess
how long it will take the reader to finish the current page: P1.


Note that both these two checkpoints should be marked as solving
"legacy" issues, as it's really the role of the UA to provide the fix
(like Lynx already does for instance, by providing a Refresh-to link
at the top of the page).

So here's my rewording of A.10.1

 Until user agents provide the ability to stop the refresh, do not use
 periodic auto-refreshing pages (using HTTP-EQUIV=refresh) [Priority 1]
 or one-time refresh in place of server redirect [Priority 2].

and we can develop the techniques with the info above.

Received on Friday, 19 February 1999 05:40:54 UTC