The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
Look at sites like book.cakephp.org. This site changes the URL without using the hash and use AJAX. I'm not sure how it does it exactly but I've been trying to figure it out. If anyone knows, let me know.
ReplyDeleteAlso github.com when looking at a navigating within a certain project.
This is similar to what Kevin said. You can have your client state as some javascript object, and when you want to save the state, you serialize the object (using JSON and base64 encoding). You can then set the fragment of the href to this string.
ReplyDeletevar encodedState = base64(json(state));var newLocation = oldLocationWithoutFragment + "#" + encodedState;document.location = newLocation; // adds new entry in browser historydocument.location.replace(newLocation); // replaces current entry in browser history
The first way will treat the new state as a new location (so the back button will take them to the previous location). The latter does not.
It is unlikely the writer wants to reload or redirect his visitor when using Ajax.
ReplyDeleteBut why not use HTML5's pushState/replaceState?
You'll be able to modify the addressbar as much as you like. Get natural looking urls, with ajax: http://www.w3.org/TR/html5/history.html#the-history-interface
Check out the code on my latest project:
http://iesus.se/
Basically your links contain anchors:
ReplyDeletepage.html#Tab1
page.html#Tab2
page.html#Tab3
And when the page loads you check document.location.href and substr the ID off the end to get the state. At least that's how I've been doing it. :(
Hopefully there's a better way.
SWFAddress works in Flash & Javascript projects and lets you create bookmarkable URLs (using the hash method mentioned above) as well as giving you back-button support.
ReplyDeletehttp://www.asual.com/swfaddress/
The window.location.hash method is the preferred way of doing things. For an explanation of how to do it,
ReplyDeleteAjax Patterns - Unique URLs.
YUI has an implementation of this pattern as a module, which includes IE specific work arounds for getting the back button working along with re-writing the address using the hash. YUI Browser History Manager.
Other frameworks have similar implementations as well. The important point is if you want the history to work along with the re-writing the address, the different browsers need different ways of handling it. (This is detailed in the first link article.)
IE needs an iframe based hack, where Firefox will produce double history using the same method.
Check if user is 'in' the page, when you click on the url bar, javascript says you are out of page.
ReplyDeleteIf you change the url bar and press 'ENTER' with the symbol '#' within it then you go into the page again, without click on the page manually with mouse cursor, then a keyboad event command (document.onkeypress) from javascript will be able to check if it's enter and active the javascript for redirection.
You can check if user is IN the page with window.onfocus and check if he's out with window.onblur.
Yeah, it's possible.
;)
If OP or others are still looking for a way to do modify browser history to enable state, using pushState and replaceState, as suggested by IESUS, is the 'right' way to do it now. It's main advantage over location.hash seems to be that it creates actual urls, not just hashes. If browser history using hashes is saved, and then revisited with javascript disabled, the app won't work, since the hashes aren't sent to the server. However, if pushState has been used, the entire route will be sent to the server, which you can then build to respond appropriately to the routes. I saw an example where the same mustache templates were used on both the server and the client side. If the client had javascript enabled, he would get snappy responses by avoiding the roundtrip to the server, but the app would work perfectly fine without the javascript. Thus, the app can gracefully degrade in the absence of javascript.
ReplyDeleteAlso, I believe there is some framework out there, with a name like history.js. For browsers that support HTML5, it uses pushState, but if the browser doesn't support that, it automatically falls back to using hashes.