META Refresh vs. Javascript Refresh

That doesn’t mean that you should use JavaScript, because in this case the effect would be the same. What it means, is that you should use a 30X redirect.

The text should’ve read “Use of meta refresh and/or javascript refresh is discouraged by the W3C, since unexpected refresh can disorient users. Meta refresh also impairs the web browser’s “back” button in some browsers (including Internet Explorer 6 and before), although most modern browsers compensate for this (Mozilla Firefox, Opera, Internet Explorer 7).”

Javascript is problematic in the same way as meta refresh is

btw, noscript tag is not allowed in header.

@David Walsh: also gmail and some of google’s javascript based apps neverminds this thing, but it invalidates the page :)

@David Walsh: of course that is true.

But I also hate timed refreshed in a page. Sometimes it becomes very frustrating while reading a very long article in a newspaper’s site.

“@Bilal Çınarlı: Functionality > validation.”

Which reinforces the point on not using JavaScript or META refresh for redirecting. It’s really annoying for regular users, but specially for screen-reader users. A “meta refresh screen reader” will surely clear any doubts you have.

@Gonzalo: If you look at the code you can see this simply refreshes the page, not redirects.

@Liam: Sorry, my mistake. But the same thing applies as with the redirects, it interrupts the experience of the user, and it’s certainly a lot more annoying for screen-reader users, who will have a hard time to resume from the point where they were reading.

And what if I’m on 3G, paying big bucks for bandwidth. Don’t use any means of automatic page refreshes…

You should use meta, because javascript suffers from the same problems as meta, but with meta the user can stop the refreshing by hitting escape. (in most browsers), while to stop the javascript, you’ll have to disable javascript all together.

@David Walsh: I also am a big fan of this statement… :) btw i like the new style of the comment panel (ooo yes i admit i wasn’t around for a while).

@Can Berkol: oops! this statment… Functionality > validation.

You need threaded comments on this blog. There’s lots of useful stuff in the comments but it gets confusing.

“We’re a bit off track here people.” – mmhhmm…
While I see the value of Functionality > validation, I don’t think we should be looking looking for reasons to invalidate the page. Why not set the redirect headers server-side? Should we be using a client-side snippet when it has the same problems as the noscript alternative? Why not use MooTools fn.delay for the redirect? Where is the morning coffee I so desperately need?

This turns out to be a nice debate. I guess server side redirection is the right technique for redirection. Both Meta and javascript redirection would break back button.

Redirecting a page to its new address ok but refreshing the page without my will, i totally disagree.

“We’re a bit off track here people. The point isn’t whether or not you should use them — it’s the method by which you use when you do use them.”

Absolutely, go ahead and use automatic refreshes. Including the exact same functionality and its bugs twice and in a non-standard way is a different matter however.

If you absolutely have to do an automatic refresh, meta tags or http headers are the way to go. Not Javascript (unless it has to be done from code) and not a mishmash.

It goes without saying if its possible to use HTTP Headers instead, you would. The point here is about how to fire redirects in the client and for that there are two ways.

The reason you combine the two is simple. META does not work on all browsers and JavaScript can be disabled in some. By using both methods you are increasing the likely-hood of support drastically as its very unlikely you will find a browser that does not support either.

You might think there is never a reason to use client-side refreshes, but when you work in a corporate world where idiots make the rules, you have to use their systems, follow their orders and produce crap. If I can make my crap work a little bit better, I am all for it.

To me, the ESPN’s code sounds fine…

To go into an entirely new direction, why not get the document’s head and inject a new element (meta) with those values! :P

Sometimes you CAN have your cake eaten in two.

@Mark: That would require a user to have JavaScript enabled AND META support, which would negate the entire point of having both methods included.

One should be used as a fall-back for the other, not both expected as requirements.

Name me a browser that’s worth supporting that supports Javascript but not http-equiv meta tags.

This is a good snippet of information, its good to go through the source code of your competitor or of a bigger site to see what they do differently. Its good to know about the meta refresh though.

I have a specialized need for refresh that has nothing to do with standard compliance or google searches since its not for a public server.
Rather for internal use, I create a status display for a number projects/applications, and use meta refresh to update the display so we can keep this status display scrolling at a number of internal displays.
All plain and simple, running on a tiny computer with no HA or clusters needed.
The problem is, if the server should fail for any reason and the reboot takes longer than the refresh time, I then have to go around to all the displays and manually refresh the local web browsers to get the displays scrolling again.
Is there a way to use java-script to refresh and try again, even if the server 404ed? (I don’t mind it showing an error while the server is down, but it shoudl start refreshing again once it’s back up)
Perhaps keeping the java-script in a frame? (but I hate frames!)