[<== Previous] | [Up] | [Next ==>]
See also Danish and
(done by others in their own site, with my permission)
TIP: Here's how to make your page automatically load
another page after a given number of seconds. Now, do you really,
really need to do this?
This message will self-destruct in 30 seconds!
Only kidding, but if I was using a "META refresh" tag on this page, it
actually would. In spy movies, that's a pretty neat thing, but when
you're trying to read a web page it could get annoying... that's why
I don't really do it here!
You've probably seen web pages that automatically move the user on to another
web page, sometimes repeatedly in slide-show fashion. Here's how to do it,
but I'll also explain why it's probably a bad idea in most sites.
How To "META-Refresh"
Use this syntax, within the <HEAD> section of the document:
The contents of the "CONTENT" attribute consist of the number of seconds until
the page load takes place, followed by a semicolon and a space, then
"URL=" followed by the URL of the site to load. Note that the "URL=" part
is within the "CONTENT=" parameter, not a separate parameter.
Since this is an
HTTP-EQUIV META tag, it is actually equivalent
to sending a
Refresh header in the server's actual HTTP headers.
If you have control of this server-level stuff, you can do refreshes directly
through the headers without having to insert a tag in your HTML documents.
(Though, it's possible there are a handful of browsers that don't like it that
way; many years ago I observed WebTV to fail to honor such headers, but that's
I should note, however, that the
Refresh header doesn't appear in any
of the standards documents regarding the HTTP protocol, so it is technically nonstandard
(whether sent as a real header or a META tag), though widely supported.
Why Not To "META-Refresh"
OK, now you know how to do it. Now here's why you probably shouldn't:
- Not all browsers necessarily support it. Somebody using an older
browser, or a browser (like Opera) that allows users to disable features
like "META refreshes", might never make it to the page they're supposed
to be shunted to, and thus be unable to see your entire site.
- Some browsers may have nasty bugs that cause a page to infinitely reload
without giving the user a chance to read it... this page
did exactly that for me in some versions of the Mozilla browser, though
its META Refresh tag seems to be valid. Use of META tags with messed-up syntax, of course,
increases the chance of such mishaps happening.
- Many users find automatic page-shunting to be very annoying. They
prefer to surf the web at their own speed, under their own control, and
resent sites that take this control away from them by moving them on
to a new page at a speed chosen by the page author rather than when the
user follows a link. Maybe the user wants more time to read the text
or view the graphics on the first page before going on to the next one,
or maybe he or she is bored with the page and wants to move on right
away, not wait 30 seconds for the refresh to move on.
- If you've scrolled down in a long page, while reading it or
while you've left the page in your browser while you went and did something
else, it's annoying to find you've been placed back at the beginning of the
page because it reloaded on you.
- The most common use of such refreshes, to show a "splash screen"
at the beginning of a site before bringing the user to the real home
page, is particularly annoying to users who went to the site to find
information, and would prefer to get the main menu right away rather
than sit through the author's attempts to "entertain" the user. This
will be especially annoying if the user's already been to the site a
few times, and is forced to sit through the opening animation yet
again. People will probably bypass this by bookmarking the real
menu page rather than the original front URL, but this isn't very
satisfactory because this URL is likely to be less memorable
(http://www.example.net/docs/real-front-page.html instead of just
http://www.example.net/), and is more prone to change in future site redesigns,
breaking all such bookmarks.
- Also, just try to use the "Back" button to back out of a site
with "refresh" pages; especially if the time interval used is very
short, you may find your browser immediately starts loading the next
page in the sequence, keeping you from going back any further unless
you press the button really rapidly. Maybe you'd like to purposely
stop people from backing out of your site (especially if you're a
marketing person and your site is trying to sell something), but users
who get annoyed this way are likely to have a bad taste in their mouth
about your site and avoid it in the future.
Why To META-Refresh
OK, enough negativity; people say I'm too negative, and all I do is
keep shooting down ideas rather than propose anything constructive.
Killing a bad idea can be a productive thing if it saves everybody
from the problems the bad stuff causes, but I will get a bit more positive
here by listing a few places where the use of these "refresh" pages
might be a useful thing:
- Interactive sites such as online games and real-time chats, which
need to load and reload pages to show what's happening in a dynamic
program. HTML is not really a very good language for such interactive
content (that's not what it was designed for), but in a pinch you can
do quite a bit with HTML, CGI scripts, and such features as the
"refresh" META tag.
- News and sports sites with continuous updates, where you might want
the page to keep reloading every 30 or 60 seconds so a user can keep
seeing the latest scores, etc. (If you omit the "URL" portion of the
Refresh content, the same page will be reloaded, including its Refresh
tag so that the new copy of the page will itself reload in the given
number of seconds, infinitely long or at least until the user leaves
the page manually.)
- Temporary pages placed at obsolete URLs to redirect users to the
new correct URL, if you don't have the low-level server access needed
to do the "cleaner" solution of having the server automatically redirect
the URLs. (The disadvantage of this, however, is that if such a move
causes the obsolete URL to seem to function normally, users never do
get any incentive to update their bookmarks and links to the new URL,
and hence you never can get rid of these "temporary" redirects; it
might be better in the long run to put up a warning page telling people
to change their links, and using a normal link to the new URL instead
of any sort of automated refresh or redirect.)
And there are probably a few other possibilities. No feature of HTML,
or anything else, is totally evil; there are always some good uses.
But some "features" are misused more often than they are properly used,
so you should think carefully before using them.
Even if you do have what seems like a good reason to
use an automatic refresh, you may still have to get rid of it...
I was in that situation a long time ago. I had used a refreshed page to
get around a technical difficulty in a site I worked on for my
employer, but when they made a new marketing deal with a major
company which involved them linking to that page, somebody at that
company objected to the refresh on the grounds that it made it difficult
for anyone to return to the original site via the BACK button. (I did
use a 2-second pause on the refresh to allow time to go back, as opposed
to some other refreshed sites that have no pause and pre-empt the BACK
button altogether, but that wasn't enough, since most users don't
figure out what's happening quick enough to hit BACK again within this
short time.) So I was forced to come up with an alternative,
non-refreshed solution really quickly. Let this be a lesson; if you're
doing a site that's anything other than your personal home page, you
may have a client, boss, affiliate, or other person who will someday
demand that you get rid of that annoying refresh right now.
It's a lot easier for you to develop the site without a refresh from the
start than it is for you to figure out how to do away with it once it's
embedded in your site's basic structure!
If you do use a refresh in your pages, at least provide a regular link
to the next page in addition to the automated refresh, for the benefit
of those with non-refresh-supporting browsers and those who don't want
to wait for the automatic refresh to kick in.
And Now For Something Even More Annoying...
code to load another page. I've encountered sites whose front pages
user's browser type, the time of day, the phase of the moon, or whatever,
and then proceeds to launch different pages in each case. Probably the
site author thought they were being pretty clever, but what this means
the browser security scares that erupt every few months when another
bug is found), ends up seeing a totally blank page. This is a really
frustrating thing to inflict on your users. And don't forget that the
search engine robots see the same thing when they're indexing your site!
One U.S. Senator had this sort of front page, and when a constituent
complained by e-mail about his inability to enter the site using the
MacWeb browser, he got a rude reply from a staffer that "90% of the
users use Netscape or Internet Explorer, so that's all we care about."
It made me wish I lived in that state so I could vote against this
Senator. Rudely turning away 10% of the voters hardly seems like good campaign
advice, not to mention the likely higher percentage of people with
implementations; do you really want to trust the whole navigation of your
site to a script language that might blow up in a different browser version?
Did you test it on all versions of all browsers?
found sites like those to be highly annoying; since they proceeded to
load pages with no time delay (unlike the META-refresh), they made
the use of the Back button nearly impossible.
- AllStocks.Com AutoRefreshing Page Builder
lets you set up a page that refreshes your favorite site, useful for monitoring stock quote,
news, and sports-score pages. It seems to do this with some combination of frames and
scripting (and claims to be seeking a patent on the technique they use). They also have
a downloadable program to automatically
[<== Previous] | [Up] | [Next ==>]
This page was first created 16 Nov 1997, and was last modified 24 Mar 2012.
Copyright © 1997-2017 by Daniel R. Tobias. All rights reserved.