Still now I knew Its not Possible to change the contents of location bar without changing the page (and Yes I am not talking about #). I've recently noticed github.com. How they are doing that on their site ? they can easily get an event when user clicks on Browser's back or next button. dojo.back also have this feature. But how to change the addressbar with javascript without leaving the page ?
There are two ways:
HTML5's pushState() function. Facebook and Github use this, for example. It allows you to modify the complete URL and fires event handlers when the history state changes. Mozilla has a good overview.
The old variant is to use the hash part of the URL (this is what Twitter does). This means that you change window.location.hash, monitor it for changes and, based on the value of that hash, load the appropriate content. However, this means that when the user requests, say, http://twitter.com/#!/27c3/status/18331752900591616, only the part before the hash sign is requested form the webserver, everything after the hash is only the client's business. This means that the server can not yet decide what content to hand to the client.
try dojo.hash
What you're referring to on GitHub is the # (hash). When you right click on a line number, it adds the number to your hash.
window.location.hash = 'HELLO';
Put that in a page to try it out. It's not possible to change window.location without the page reloading. The back button stuff is a little trickier, but Dojo is your best bet for that. jQuery doesn't provide this. Dojo has pretty clean code though, so you should be able to reverse engineer their functions (if you chose to include that functionality into your own library).
You'll also notice Google is doing the same with: http://code.google.com/p/digitalxero/source/browse/#svn%2Ftrunk%2Flocale%2Fde
If you click on folders (left), it changes the hash, and provides different content.
Related
Okay so there are solutions for this as in Modify the URL without reloading the page but I have one question regarding this.
So here is what I plan to do (let's assume my web address is example.com)
1. using pushState I plan to change the browser address to example.com/myprofile/myalbum. So to be clear, this new url may or may not exists but the browser address is changed regardless. In our case this url doesn't actually exist but we are using the address to mark a changed state of the webpage.
2. use ajax to load data regarding "myprofile > myalbum" to the same page.
But now here's the issue I have been thinking about. What if a user loads example.com/myprofile/myalbum directly on a, let's say, new tab. This page clearly throws a not found error because it doesn't exist.
So how do I load ajax corresponding to this fake url? For example http://www.usatoday.com/news/ seems to do this well (unless that's an iframe, which wouldn't be so nice).
You can add rewrite rules to your webserver, converting either specific URL's or some matching a pattern to something that your scripts can use to show the right page. You can have it rewrite the URL only internally, so the user still see the original URL in the browser. Such as:
RewriteRule /myprofile/(\w*) /index.php?path=/myprofile/$1
Different webservers will probably have different syntax, but they will be similar.
I want to make a page with a lot of Javascript interactions. However, while a user navigates through the page the URL must change too. So, when the user shares the URL or saves it, it can lead him to the actual state he was.
How can I do that?
Examples:
myapp.com/page1
myapp.com/page2
pushState, as seen on github
Answered by this SO question: Change the URL in the browser without loading the new page using JavaScript
The only part of the url (or location) that you can change without reloading the page, is the hash. That is the part behind the #. Many ajax enhanced applications make use of this, including Twitter. You can change this hash on the go, and interpret the hash tag on page load to initialize the page to the correct state.
Set this value: window.location.href
window.location.href = "myapp.com/page2";
Note: The question is not how to fix the problem, as that is documented elsewhere on SO (e.g., Integrating Facebook to the leads to blank pages on some browsers / fb_xd_fragment).
1) What causes this, and under what conditions is it triggered?
2) More importantly, does this affect end users at all? For instance, how does this bug affect the URL shared by someone who clicks the FB Like button? If someone clicks the FB Like button from URL A, does URL A still get shared (but with "fb_xd_fragment" appended), or does URL A become your root URL (with "fb_xd_fragment")? In our logs, all the URLs appear as the root URL with "fb_xd_fragment" appended, so we're not sure if this is because people are clicking the Like button from the home page, or if all the shared URLs get morphed into the root URL.
Basically, what happens is whenever you use the JS API it opens your site in another iframe to use as a cross-domain receiver. What you can do is set a custom channel URL and it will use that instead. If seeing this bothers you, you can set a custom channel url. More information on http://developers.facebook.com/docs/reference/javascript/FB.init/
I've been looking for some javascript hooks for the back button in the browser. But they only seem to support back/forward between hashed url's. That is, you can only navigate from www.mysite.com#page1 and www.mysite.com#page2, if you click back, and the url becomes something without a hash, they all fail. Like this one: http://www.asual.com/jquery/address/samples/tabs/ Click one tab, then back, it won't work.
But on http://www.beautyoftheweb.com they've managed to get the backbutton to work between hashed and non-hashed url's. Any idea how they've done this?
Are you sure? I'm seeing a hash:
http://www.beautyoftheweb.com/#/highlights/all-around-fast
^-- here
But assuming there are some URLs that don't have them: What kind of failures are you seeing elsewhere? I have an intranet app where I'm using Really Simple History for history management, and you can happily go backward and forward between URLs whether or not they're application URLs using the hash, application URLs not using the hash, or completely unrelated URLs for other pages/apps. (You can also bookmark the hashed ones, and the app comes back to the right place when you use it.) That works in my app because on initial load, I look to see what hash (if any) is present and reload that state as necessary. (I don't rely on — or even use — RSH's data-storage aspect, just the hash manipulations.)
Edit Just tried the live demo of the first jQuery history plug-in I found in a quick search. It handled going back and forth between "hashed" and "unhashed" URLs just fine. I went to the "#2" link, then edited the URL in the address bar to remove the hash entirely and pressed Enter. That took me to the correct page. Then clicking Back I got the "#2" page correctly. In fact, if you go here I'm linking directly to the "#2" link, and it loads its state accordingly. I think you've been seeing some naive use of history libraries where the coder hasn't handled the initial load correctly.
From what I see, all the URLs are of the form http://www.beautyoftheweb.com/#/<something>, for example: http://www.beautyoftheweb.com/#/experience/cnn - hence, all are using hashes.
I've never learnt JavaScript, but I imagine this is quite a simple problem. Just wanted to know which method is most advised these days.
// use this to avoid redirects when a user clicks "back" in their browser
window.location.replace('http://somewhereelse.com');
// use this to redirect, a back button call will trigger the redirection again
window.location.href = "http://somewhereelse.com";
// given for completeness, essentially an alias to window.location.href
window.location = "http://somewhereelse.com";
edit: looks like the user who posted the better answer has left SO, i've consolidated his answers here.
Most advised? To not do it. HTTP is far better suited to the job than JavaScript is (search engines follow them, you can state if it is permanent or not, they are faster, etc).
Failing that…
If you want an immediate redirect:
window.location.replace('http://example.com/');
This will replace the current URI with the new URI in the browser history, so the back button won't land the user on a page that immediately throws them forward again.
If you don't really want to redirect, but want to send the user somewhere in response to an event:
window.location.href = 'http://example.com/';
Remember to have a non-JavaScript fallback. A link is usually the best option, but it does depend on context.
Time delayed redirects are an even worse idea. The only reason to use them is if you want to display a message to the user - and users read things at different speeds (and have them sitting in another tab while they do something else). If the message is important enough to show, then it should be important enough to leave on screen until the user has read it and clicked a link to the next page.
One important thing to remember when redirecting a page using JavaScript is, always provide a non-JavaScript redirect as well! A link would do, or better a <META> tag, for example: <meta http-equiv="refresh" content="2;url=http://example.com">
These days, I think the most advised method is not to do javascript (or meta) redirects. Do you really need it ? Could you use a redirect HTTP header instead ?
The W3C's Web Content Accessibility Guidelines (7.4) also discourage the creation of auto-refreshing pages, since most web browsers do not allow the user to disable or control the refresh rate