META Refresh vs. JavaScript Refresh
A few days back I was perusing the ESPN.com source code when I found the following snippet of code:
<script>
ESPN_refresh=window.setTimeout(function(){window.location.href=window.location.href},900000);
</script>
<noscript>
<meta http-equiv="refresh" content="900" />
</noscript>
I understand what the code was supposed to do but was confused as to why they'd use JavaScript as a primary method and META as a fallback method. Why not just use the META method? I did some research and found the answer at Wikipedia:
Use of meta 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).
So there you have it. Use JavaScript as your primary means for automatic page refreshes and a META tag as your fallback.
![Create Namespaced Classes with MooTools]()
MooTools has always gotten a bit of grief for not inherently using and standardizing namespaced-based JavaScript classes like the Dojo Toolkit does. Many developers create their classes as globals which is generally frowned up. I mostly disagree with that stance, but each to their own. In any event...
![I’m an Impostor]()
This is the hardest thing I've ever had to write, much less admit to myself. I've written resignation letters from jobs I've loved, I've ended relationships, I've failed at a host of tasks, and let myself down in my life. All of those feelings were very...
![Dress Up Your Select Elements with FauxSelect]()
I received an email from Ben Delaney a few weeks back about an interesting MooTools script he had written. His script was called FauxSelect and took a list of elements (UL / LI) and transformed it into a beautiful Mac-like SELECT element.
![HTML5’s window.postMessage API]()
One of the little known HTML5 APIs is the window.postMessage API. window.postMessage allows for sending data messages between two windows/frames across domains. Essentially window.postMessage acts as cross-domain AJAX without the server shims. Let's take a look at how window.postMessage works and how you...
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.
@Bilal Çınarlı: The WorldWide Leader in Sports disagrees. :)
@David Walsh: also gmail and some of google’s javascript based apps neverminds this thing, but it invalidates the page :)
@Bilal Çınarlı: Functionality > validation.
@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…
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.
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!)
I use meta refresh when i want to go to a page which takes long to load (dynamic session and stuff), when using javascript
window.locationmy spinner doesn’t do any animation, with meta refresh this animated gif still works so the user sees it is actually doing something. So not always use JavaScript at all :-)The reason I use setTimeout() is because the meta refresh tag cannot be stopped or altered. I have pop up forms (in a jquery lightbox) that when they open, I need to make sure the page doesn’t refresh while the user is working with that form. Since it is part of the page, the form will vanish from in front of their eyes if the refresh comes around. Once the windows closes, the page can go back to it’s normal refresh. It’s basically a continuously updating “Status Board” that occasionally needs to be interrupted to fill in a form.
Ethically, why do a refresh? The only reason to do one is to scam extra pageviews, right?
i want to know a step by step insructions of how to insert java script and meta refresh tag can you show me the step on how to do this, im using the google chrome with the dev tools and inspect element please get back to me
I use this on a page displayed on big screens with no user input, so it’s very useful here. If there’s a better way please let me know.