By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,407 Members | 1,753 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,407 IT Pros & Developers. It's quick & easy.

Javascript or Meta Refresh?

P: n/a
Hi,

I am trying to do some refactoring of a web site to ensure that it displays in
the most web clients possible. One of the pages requires to be redirected to
another automatically, for one reason or another. My style is usually to reduce
the use of Javascript, as much as possible, as in my experience it often causes
compatibility issues. Anyhow, the page currently has:

....

<body>

<script>
window.location.replace("actions");
</script>

</body>

....

I am tempted to replace this with a meta tag to change the page:

<META HTTP-EQUIV=Refresh CONTENT="1; URL=action">

Would this have any limitations, and what do you believe to be the most
compatible or best solution for the task.

regards

Tarx
Jul 20 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
Tarken wrote:

One of the pages requires to be redirected to
another automatically, for one reason or another.
And what are those reasons?
<script>
window.location.replace("actions");
</script>
Fails in browsers w/out js.
<META HTTP-EQUIV=Refresh CONTENT="1; URL=action">
Better, I suppose, but really this is a poor replacement for real http
headers.
Would this have any limitations,
AFAIK, some clients such as Lynx don't support it.
and what do you believe to be the most
compatible or best solution for the task.


Server redirect, with an appropriate HTTP status code (either 301 or 302).

--
Brian
follow the directions in my address to email me

Jul 20 '05 #2

P: n/a
Tarken wrote:
I am trying to do some refactoring of a web site to ensure that it
displays in the most web clients possible. One of the pages requires to be
redirected to another automatically, for one reason or another. My style
is usually to reduce the use of Javascript, as much as possible, as in my
experience it often causes compatibility issues.
<snip> Fugly JS and META </snip>
Would this have any limitations, and what do you believe to be the most
compatible or best solution for the task.


Rather then trying to have the document redirect, or software running from
the document, do it with the system that gets the document for the user.
i.e. an http redirect.

How you do this depends on why you want to redirect (permenant / temporary),
and the software that runs the website (Apache? IIS? Any server side
scripting language available?)

--
David Dorward http://dorward.me.uk/
Jul 20 '05 #3

P: n/a
On Wed, 12 Nov 2003, Brian wrote:
Tarken wrote:

One of the pages requires to be redirected to
another automatically, for one reason or another.
And what are those reasons?


Just what I was going to ask.
<script>
window.location.replace("actions");
</script>


Fails in browsers w/out js.


See also http://www.w3.org/TR/WCAG10/#gl-movement
<META HTTP-EQUIV=Refresh CONTENT="1; URL=action">


Better, I suppose,


Since we don't know the motive yet, I don't think we can evaluate the
proposed solution. But again: _if_ this does what the author
intended, then it's in violation of that WAI guideline, as well as
being a nuisance for some quite ordinary users.
but really this is a poor replacement for real http headers.
Again, we really need to know what this is supposed to be _for_.

Is the author trying to present the user with a brief look at
something, for a not very clearly defined period of about 1 second?
Then not only does it not work very well, but it upsets the WAI (and
rightly so IMHO). On the other hand there can be justifiable uses for
pages which auto-refresh at intervals - but then the intervals would
normally want to be much longer, say 60 secs or more (and the WAI
would want you to provide a non-refreshing version for users who want
it).
Would this have any limitations,


AFAIK, some clients such as Lynx don't support it.


From the point of view of the user, Lynx "supports" the META...refresh
very well indeed; it politely informs the user that the author wanted
to go to another URL after a certain time, and then politely waits for
the user to decide what _they_ want to do about it. You can't get
much user-friendlier than that, hmmm?
Server redirect, with an appropriate HTTP status code (either 301 or 302).


If there was no intention for the reader to ever get to see the first
page, then you're absolutely right. And the WAI guidelines agree with
you: see http://www.w3.org/TR/WCAG10-HTML-TECHS/#script-refresh ,
second bullet.

cheers
Jul 20 '05 #4

P: n/a
Alan J. Flavell wrote:
On Wed, 12 Nov 2003, Brian wrote:
Tarken wrote:
One of the pages requires to be redirected to another
automatically, for one reason or another. <META HTTP-EQUIV=Refresh CONTENT="1; URL=action">
Better, I suppose,


Since we don't know the motive yet, I don't think we can evaluate
the proposed solution.


Perhaps I guessed too much. I read "redirected to another page" and
thought it was an attempt to redirect to another url without a delay.
But the proposed meta http-equiv statement does allow for other
possibilities.
AFAIK, some clients such as Lynx don't support it.


From the point of view of the user, Lynx "supports" the
META...refresh very well indeed;


Indeed, but not in the way that many authors had hoped. ;-)
it politely informs the user that the author wanted to go to
another URL after a certain time, and then politely waits for the
user to decide what _they_ want to do about it.
Yes, of course, I stand corrected.
You can't get much user-friendlier than that, hmmm?
Well, come to think of it, no. On this matter, Lynx is quite good.
In fact, I wish my other browsers did what Lynx does.
see http://www.w3.org/TR/WCAG10-HTML-TECHS/#script-refresh, second
bullet.


I don't quite follow that. I understand that server redirects are
better for updating indexes and directories, perhaps even bookmarks
some day, and are more reliable then e.g. client side scripting. But
I don't see how auto redirects on the client side hinder
accessibility. Care to elaborate?

--
Brian
follow the directions in my address to email me

Jul 20 '05 #5

P: n/a
On Thu, 13 Nov 2003, Brian wrote:
see http://www.w3.org/TR/WCAG10-HTML-TECHS/#script-refresh, second
bullet.
I don't quite follow that. I understand that server redirects are
better for updating indexes and directories, perhaps even bookmarks
some day, and are more reliable then e.g. client side scripting.


Yup, everthing that you said...
I don't see how auto redirects on the client side hinder
accessibility. Care to elaborate?


Well, they start to display one URL, and then go and display another.
Which is confusing for accessibility technologies, and can wreck the
browser's own Back function. Depends a bit on how much delay is
specified (one could argue that accessibility clients *should* have
some kind of special treatment for short refresh times in META, so
that their user wasn't inconvenienced; but at the time the guidelines
were formulated, that option was rarely available, so, while the User
Agent guidelines were calling for appropriate facilities in browsers,
the Web Content guidelines were saying to avoid provoking the
situation that would need such facilities.)

Anyway: if it's only about redirecting to another URL, then
meta...refresh is the wrong technology. As you said, HTTP status 30x
is the right answer. If, on the other hand, it's about periodically
updating a view into something that's changing, then that could be
different, the meta...refresh is arguably a possible solution, but it
still needs some provision for WAI "until user agents support..." a
user control over it.
Jul 20 '05 #6

P: n/a
Brian <us*****@julietremblay.com.invalid-remove-this-part> wrote in
news:JjBsb.186712$e01.677430@attbi_s02:
Alan J. Flavell wrote:
see http://www.w3.org/TR/WCAG10-HTML-TECHS/#script-refresh, second
bullet.


I don't quite follow that. I understand that server redirects are
better for updating indexes and directories, perhaps even bookmarks
some day, and are more reliable then e.g. client side scripting. But
I don't see how auto redirects on the client side hinder
accessibility. Care to elaborate?


As far as I can tell, items 7.4 and 7.5 really address cases where the
redirection isn't intended to be completely transparent to the user; rather
the user is expected to read something before the refresh occurs. In those
cases, the refresh could occur too quickly if the user was a slow reader,
had to scroll because he was using highly magnified text, etc. I don't see
an accessibility problem with transparent refreshes, but I do see a
usability problem, as a near-instantaneous refresh can effectively disable
the back button. Come to think of it, that *does* create an accessibility
problem, since users who can't repeatedly click very quickly won't be able
to break out.

So the option would then be a transparent refresh that involves a
substantial pause with nothing to read for the duration, which simply adds
to the perceived load time of the final page. But then you're sacrificing
everybody's experience for a purely nominal gain in accessibility, which is
the sort of thing that drives resentments (in fact, it would be close to
the original meaning of the now-meaningless phrase "political correctness"
which was along the lines of "talks the talk but doesn't walk the walk").
Jul 20 '05 #7

P: n/a
Brian wrote:
Tarken wrote:
One of the pages requires to be redirected to
another automatically, for one reason or another.

<META HTTP-EQUIV=Refresh CONTENT="1; URL=action">


Better, I suppose, but really this is a poor replacement for real http
headers.

Server redirect, with an appropriate HTTP status code (either 301 or 302).


This advice comes up quite often.
It ought to be a FAQ, if it isn't already.
It's probably outside the scope of this group, but can anybody tell me,
or tell me where to ask, how exactly this is done ?

There's two parts: (a) what exactly should the http responses be ?
I've fished around in various http documents in the past, but I've never
found anything well written, with good examples.

(b) how do I get my server to deliver a particular response ?
I know the answer's different for different servers.
My primary interest would be in the OSU HTTP_SERVER, running on VMS; but
answers for IIS & Apache would be of interest too.

Thanks,
Chris

Jul 20 '05 #8

P: n/a
Tarken wrote:
I am tempted to replace this with a meta tag to change the page:

<META HTTP-EQUIV=Refresh CONTENT="1; URL=action">

Would this have any limitations, and what do you believe to be the most
compatible or best solution for the task.


http://www.w3.org/QA/Tips/reback

--
Stanimir

Jul 20 '05 #9

P: n/a
On Thu, 13 Nov 2003, Chris Sharman wrote:
It's probably outside the scope of this group, but can anybody tell me,
The details are generally specific to the server, and so are on-topic
for the group that deals with the HTTP server that you use
(comp.infosystems.www.servers.*). Unless you're doing it with some
kind of cross-server technology such as CGI (for Perl CGI see CGI.pm),
PHP, etc. in which case you'd consult their documentation, and rely on
them getting the details right for you, no?
There's two parts: (a) what exactly should the http responses be ?
If you want an "exact" answer, then you'd need to consult RFC2616.
Can't get more exact than that ;-)
I've fished around in various http documents in the past, but I've never
found anything well written, with good examples.
I thought there was a note at the W3C, but for some reason I can't
find anything now.
(b) how do I get my server to deliver a particular response ?


This (found by Google) looks relevant, if you can read it (bah!
microfonts). http://www.seoconsultants.com/w3c/status-codes.asp

Jul 20 '05 #10

P: n/a
Brian <us*****@julietremblay.com.invalid-remove-this-part> wrote in message news:<0Pxsb.135189$9E1.670818@attbi_s52>...
Tarken wrote:

One of the pages requires to be redirected to
another automatically, for one reason or another.


And what are those reasons?


Fair question. In reality this part is to do with a Java web
application. The first page in the web application is index.html.
There is a servlet in the
application called 'actions'. All the logic for the web application is
in
the servlet, hence why the redirect from the index.html page. The
servlet
does not use the base context of the web application, because it still
needs
to be able to share images, which are referenced in the displayed
pages.
Talking to the original author it turns out that the added advantage
of
the javascript rewrite, is that not only does it change pages, but it
also
rewrites the URL used by the user.

I would like to find an approach that is the most universally
compatible, browser wise, for changing page. I am not sure whether I
should be putting
the logic into the browser, or into the web application.

regards

Tarx
Jul 20 '05 #11

P: n/a
In article <e9**************************@posting.google.com >,
ta****@lycos.co.uk (Tarken) wrote:

[snipped java applect that wants to wield javascript redirects]
I would like to find an approach that is the most universally
compatible, browser wise, for changing page. I am not sure whether I
should be putting
the logic into the browser, or into the web application.


My approach would be to contain it to the java application, since that
is already an optional browser feature. Making the functionality of the
application rely on *two* optional technologies makes the ground only
shakier.

What if the applet could do without the JavaScript and the JavaScript
would only be responsible for changing the appearance of the URL when
the Java applet tells it so? That's something that dresses it up a bit,
but can be missed if not available.

However, I am no Java engineer, nor a very proficient JavaScript author.

--
Kris
kr*******@xs4all.netherlands (nl)
Jul 20 '05 #12

P: n/a
Kris <kr*******@xs4all.netherlands> wrote in message news:<kr*****************************@news1.news.x s4all.nl>...
In article <e9**************************@posting.google.com >,
ta****@lycos.co.uk (Tarken) wrote:

[snipped java applect that wants to wield javascript redirects]
I would like to find an approach that is the most universally
compatible, browser wise, for changing page. I am not sure whether I
should be putting
the logic into the browser, or into the web application.


My approach would be to contain it to the java application, since that
is already an optional browser feature. Making the functionality of the
application rely on *two* optional technologies makes the ground only
shakier.

What if the applet could do without the JavaScript and the JavaScript
would only be responsible for changing the appearance of the URL when
the Java applet tells it so? That's something that dresses it up a bit,
but can be missed if not available.

However, I am no Java engineer, nor a very proficient JavaScript author.


Turns out I can create an index.jsp with the body:
<%response.sendRedirect("myRelativeURL"); %>

Beyond that I am in the wrong group ;)

Thanks for your help

Tarx
Jul 20 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.