Go to http://www.facebook.com/facebook?v=wall, then click on the info tab. The content will be loaded, and the address bar now becomes http://www.facebook.com/facebook?v=info but the webpage didn't reload.
At first I think it is Ajax, but my question is, how do you change the address bar without reloading? I know I can change anchor (#wall) using JS but querystring (?v=wall), how?
It's using HTML5's new history.pushState() feature to allow the page to masquerade as being at a different URL to that from which it was originally fetched.
This seems only to be supported by WebKit at the moment, which is why the rest of us are seeing ?v=wall#!/facebook?v=info instead of ?v=info.
The feature allows dynamically-loaded pages to be properly bookmarked, exchanged etc between JS-supporting and non-JS-supporting user agents. Because if you as a JS user linked someone to ?v=wall#!/facebook?v=info and their browser didn't support JS and XMLHttpRequest, the page wouldn't work for them. The #! is also used as a tip to search engines to download the non-AJAX version.
#Snoob - I'd appreciate it if you accepted #bobince's answer instead, he's was on the right track about the specifics first here. Since I can't delete/remove this until it's unaccepted I'll update it to be as correct as possible.
At the moment it's a WebKit (Chrome, Safari, etc.) specific thing you're seeing (or rather, not seeing), as #bobince points out in other browsers you can see the real URL in the bar:
http://www.facebook.com/facebook?v=wall#!/facebook?v=info\
Where Chrome just shows:
http://www.facebook.com/facebook?v=info
It makes a bit of sense, given this is how you make AJAX Content crawlable with the Google search engine, so their browser recognizes where the content comes from as well.
Correction on the specifics: Webkit browsers are showing the shortened URL facebook wants using the HTML 5 history features you can see the code here (take a look at the HistoryManager) in this case specifically they're using .replaceState() to replace the URL you went to with the direct one available.
Note: This answer may not be valid later (the WebKit specific bit), as other browsers support HTML5 features more and more this may become outdated quickly.
For MooTools developers I recommend checking out cpojer's mootools-history plugin which provides support for the native history API when available, with a fallback to hashes.
I don't have Facebook so I can't check. But I'm 95% sure that it has to be a full page request, the location bar is unwritable because this would be a very useful feature to absure for phishing websites (instead of http://fakeonlinebank.com it rewrite to http://yourtrustybank). It's probably just so fast that your browser appears to only load that part?
But I'm curious to see if someone will correct me on this, because that would mean they have the answer you do want to hear ;)
Related
I'm using the history.js plugin (https://github.com/browserstate/history.js/) to give elements on a page a certain unique url when opened.
As expected, this works great in HTML5 browsers, but the plugin isn't quite doing what I need in HTML4 browsers (Internet Explorer, in other words).
Basically, I'm having the same pitfall that is outlined in the documentation for the plugin, as seen here:
These issues are unavoidable if hashes are used.
URLs get polluted if we did not start on the home page
http://www.facebook.com/balupton#!/balupton?sk=info
http://mywebsite.com/page1#/page2
Although, my URLs are not quite as bad as this, other than the hash being thrown in, the url is usable. Removing the suid at the end would also be nice, as it isn't necessary in my case, but it should be fine if that's not possible.
Here is what my URL needs to look like:
http://domain.com/sitename/main/item/109
And this is the result in IE:
http://domain.com/sitename/#main/idea/109?&_suid=13812466306670658...
As far as I could gather from the documentation was that my only option would be to disable the HTML4 fallback, which means that nothing will happen in IE.
I'm wondering if theres a way to just forgo the HTML4 fallback options, but still use the HTML5 solution in it's place (to change the url in the same way it does, just with a different method.. I know that the method used for the HTML5 solution won't work). Or, if there's any other way to alter the way that the HTML4 solution is implemented, to bend it to the needs of this project?
UPDATE: In my own research, I am seeming to find that it is impossible to alter an HTML4 compliant browser's url without using a hash. I'm currently in the process of integrating some workarounds into my project so that our URLs use hashes. I'm still leaving this question open as this isn't really an answer, and I don't even know if I am 100% right.
If it's still needed, the partial answer to cleaner URL for you would be solution below.
Try code below regarding to https://github.com/browserstate/history.js/
History.options.disableSuid
Force History not to append suid
In my search for a Javascript way to programmatically select WebView content, I encountered this Javascript code snippet, which uses a method named setData() in a member named clipboardData in the window object.
But when I tried to find documentation for it in a Javascript reference, clipboardData was nowhere to be found.
Why?
Isn't window.clipboardData not part of Javascript or DOM?
No, it's not part of any standard. Except for IE, most browsers don't allow clipboard access because of security concerns (you don't want arbitrary webpages reading something sensitive information that you put into your clipboard).
I believe only IE lets you access the clipboard. Older versions of other browsers used to, but this has been switched off by default as a security measure. Users can explicitly turn it on via settings/options/preferences, but this is obviously not ideal in most situations.
The workaround is to use a flash object on the page. Since Flash 10 added more security layers, user interaction is also required now with the flash object (e.g. a click rather than say onload event).
I found and implemented the good work from the well written article at the bottom of my answer. He explains the issue in more detail, with links to official statements from Adobe/Mozilla and supplies a usable and a downloadable example, and the source code to the fla. This is handy if you want to reskin/redesign his button.
I have tested successfully on Windows7 using latest (as at 7/7/2011) Chrome/Safari/RockMelt/FF/IE7/IE8/IE9 and MacOSX(SL) Safari/FF.
The only downside is that it uses flash which is mostly fine except for some mobile platforms and a small portion of (ab)normal users. Also I found you need to access over http (a web server), opening and using the demo page via the file system (i.e. double clicking the html file in Explorer) won't work.
Thanks for sharing Rahul, awesome job.
http://www.rahulsingla.com/blog/2010/03/cross-browser-approach-to-copy-content-to-clipboard-with-javascript
I just noticed a recent change when browsing github repositorys. When you select a file or folder, the new file slides in and pushed the old file out. This is easy enough to do with jquery, but what's really different is that the URL itself actually changes so that bookmarks still work. I've been struggling to create this for a book navigating site I'm working on but haven't been able to update the url without a full page refresh. Any ideas on how github does this?
It's using the new HTML5 API history.pushState/history.replaceState for doing this (so it only works in modern browsers).
See https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history#Adding_and_modifying_history_entries for more details.
If you want a solution for all browsers, then you have to stick to modifying the fragment (the bit after the #)
I haven't looked at the underlying code, but I believe it is a combination of the new HTML5 spec of web history and location (well, location is old, but it's an updated spec).
Mozilla docs
W3C history spec
W3C location spec
The W3C specs are very verbose (after all, they are specs), so that can be hard to read. I think this other answer on Stack Overflow is in the right direction.
You have to keep in mind that this is part of the HTML5 specs, so not every browser will be able to handle this functionality. We are building this type of navigation out on a project at work, and if the browser doesn't support this feature, it's just a regular page refresh.
I'm trying to implement a decent navigation in a AJAX application. What I am doing right now is the following:
Every time a user clicks an AJAX link, the corresponding call is performed and the hash is changed.
Whenever a new page is loaded, I check whether the hash is present and make the corresponding AJAX call to update the page. This ensures that bookmarks will work as expected.
Every 500ms I check if the hash is changed and perform the corresponding AJAX call. This takes care of users pressing the back/forward buttons, albeit with a sligth delay.
The third point is a bit annoying: I'd rather not have a timeout every 500ms just to check the hash, as most of the time it will stay the same.
Is there a better way to manage this? I cannot think of any alternatives, but maybe I am missing something.
Please, do not point me towards ready-made solutions, unless you know they are based on a different mechanism.
There is the "hashchange" event, which is to be implemented in HTML5. I'm not sure how good support is now... IE8 supports it, and I think Mozilla have their own implementation in a recent release. Other than that, there is nothing I'm afraid. Checking exery x ms is the way everyone does it.
maybe this is an interesting read, it is a ready made solution for the exact thing you are doing.
and no, until the hashchange is properly supported in every browser (read: ie), you will have to check manually
Use this plugin: http://www.asual.com/jquery/address/
The jQuery Address plugin provides powerful deep linking capabilities and allows the creation of unique virtual addresses that can point to a website section or an application state. It enables a number of important capabilities including:
Bookmarking in a browser or social website
Sending links via email or instant messenger
Finding specific content using the major search engines
Utilizing browser history and reload buttons
Go to http://www.facebook.com/facebook?v=wall, then click on the info tab. The content will be loaded, and the address bar now becomes http://www.facebook.com/facebook?v=info but the webpage didn't reload.
At first I think it is Ajax, but my question is, how do you change the address bar without reloading? I know I can change anchor (#wall) using JS but querystring (?v=wall), how?
It's using HTML5's new history.pushState() feature to allow the page to masquerade as being at a different URL to that from which it was originally fetched.
This seems only to be supported by WebKit at the moment, which is why the rest of us are seeing ?v=wall#!/facebook?v=info instead of ?v=info.
The feature allows dynamically-loaded pages to be properly bookmarked, exchanged etc between JS-supporting and non-JS-supporting user agents. Because if you as a JS user linked someone to ?v=wall#!/facebook?v=info and their browser didn't support JS and XMLHttpRequest, the page wouldn't work for them. The #! is also used as a tip to search engines to download the non-AJAX version.
#Snoob - I'd appreciate it if you accepted #bobince's answer instead, he's was on the right track about the specifics first here. Since I can't delete/remove this until it's unaccepted I'll update it to be as correct as possible.
At the moment it's a WebKit (Chrome, Safari, etc.) specific thing you're seeing (or rather, not seeing), as #bobince points out in other browsers you can see the real URL in the bar:
http://www.facebook.com/facebook?v=wall#!/facebook?v=info\
Where Chrome just shows:
http://www.facebook.com/facebook?v=info
It makes a bit of sense, given this is how you make AJAX Content crawlable with the Google search engine, so their browser recognizes where the content comes from as well.
Correction on the specifics: Webkit browsers are showing the shortened URL facebook wants using the HTML 5 history features you can see the code here (take a look at the HistoryManager) in this case specifically they're using .replaceState() to replace the URL you went to with the direct one available.
Note: This answer may not be valid later (the WebKit specific bit), as other browsers support HTML5 features more and more this may become outdated quickly.
For MooTools developers I recommend checking out cpojer's mootools-history plugin which provides support for the native history API when available, with a fallback to hashes.
I don't have Facebook so I can't check. But I'm 95% sure that it has to be a full page request, the location bar is unwritable because this would be a very useful feature to absure for phishing websites (instead of http://fakeonlinebank.com it rewrite to http://yourtrustybank). It's probably just so fast that your browser appears to only load that part?
But I'm curious to see if someone will correct me on this, because that would mean they have the answer you do want to hear ;)