I have a problem with a javascript set of functions that I made.
This functions walk the entire Html page and then add the onclick event to every anchor it finds.
It do some check on the anchor href and redirect to it (using window.location.href)
My problem is that the cronology don't work properly this way, and the :visited selector don't work anymore.
How I can preserve the chronology and let the :visited selector work properly?
Regards
There's no need to set location.href manually: The link will be followed properly if you don't prevent it explicitly via returning false or calling event.preventDefault() (event.returnValue = false in IE) in the onclick handler.
Are you tracking their visits for that session?
If so, what about a server side solution instead of using Javascript.
Each time you serve up a page request, you log that Url, Page Title, etc, into their session - That way you can keep track of where they have been.
In that regard, the :visited tags will still work and you'll have a somewhat more reliable source for page history.
Use jQuery?
$('a').live('click', function(event){
// do something
});
As long as you don't call event.preventDefault in that function you should be fine.
Related
I have a javascript file that I am loading for some of the pages for tracking different events. Javascript has a list of selectors and just attaches listeners to them and call a tracking api when selectors are clicked.
Some of the elements are links. I am wondering if there is a possible case when navigation to links href will be done before the attached listener will run and call the tracking api.
Don't know if this can help you, but to navigate to the URL and logging after it, would'nt this be the same as logging on each page load? You might be able to get the URL of traffic origin to trace everything.
Or, if you implement pjax, or load in new pages through ajax, you can wait for the new page to load and log the request after the loading is done.
Or, you could end up doing some voodoo like this:
$(document).on('click', 'a:not([href="#"])', function(e) {
e.preventDefault();
// Do logging here
window.location = $(this).attr('href');
});
(edit: oh yeah, I used jQuery...)
Since you already have specific selectors for the elements you bind the tracking event to, you could simply target all links with said selector, prevent the default behaviour with preventDefault(), call the tracking api and redirect (possible as a callback if the api call allows it) to the url in href property of the link.
I have been using hashes to pass data between pages (like setting scrollTop(), etc.) and have also used the hashChange event to trigger changes on a given page.
However, hashes have default behaviors that I'm not necessarily interested in, like making the page jump to a given (sometimes insignificant) spot.
I feel like getting/setting a query string would be more logical, but:
Is it?
Is there an event I can listen for when the query string is set?
Are there query-string-related behaviors I should know about?
It depends on what you're doing.
A query string change will always trigger a page reload. The only part of the URL you can change without a page reload is the #-part.
In javascript applications, page loads are generally not okay. But it may be possible to use when having a traditional html page request/response model.
There's no event AFAIK though, since it will change page.
As the other answer says, changing the query string will cause a page reload. As far as the browser is concerned you'll then be on a completely new page.
There are events that will fire when you do this. The ’beforeunload` event will fire, however it won't be very useful as it also fires when the user clicks on a link or closes the window.
Effectively the event that will fire if you change the query string will be the load event on the new page that it loads.
It is illogical to reinvent anchor behaviour. It is better to not expose hash links to insignificant fragments (although modern browsers are doing scrollIntoView() for any element with id, there is a dedicated behaviour for <a name="xxx">). So, answer is yes here, page arguments should be passed via querystring.
Event is window.beforeunload, yes, page reload when javascript:void(location.search='some') has been set
There are no surprises, have a look
Also, on working with querystring: http://xkr.us/js/querystring
How do I change the URL with jQuery without reloading the page?
Set location.hash
jQuery has nothing to do with it though, this is basic DOM 0.
You can only change the hash part of an url without a page refresh through location.hash.
Adding get parameters (?foo=bar) or a complete url change will always reload the page.
In HTML5 you get more options to change URL's, but right now (2010) it's not yet viable since crappy browser die out hard.
In general, leaving aside the new HTML history API, you can't.
It is possible to add data to the URL after the hash (using location.hash as David Dorward describes). However, if you want to do this to affect behaviour of the page, you will also need to read these changes via jQuery (or triggered by the same process that sets the hash.)
Outside of the History API you will not be able to add a parameter, and have the page 'just know about it'.
I'm currently developing an ajax application and I'm looking for a feature that lets me intercept all static and dynamic links using javascript. The links look like these:
link 1
link 2
etc.
I then want the browser to redirect to: current.page/#link1/ rather than current.page/link1/. I'm using jQuery, so the live() function is an option, however using that as a solution just seems rather sluggish to me(am I hysterical?). If there is a way to intercept ALL links on a page, maybe through detecting a change in the address, that would greatly help. I've tried a few plugins for jQuery (jQuery address & SWFaddress) but they only seem to have event handlers that respond to changes in anchor tags in the address. Any ideas?
thanks for your time
Don't worry to much about performance unless you have to. Often the elegant solution is also the right one.
I would use jQuerys live function, bind to the click event and rewrite the link as it is being clicked on.
Hope this helps, Egil.
What the live function does is it binds an event handler to the document, which catches all click events and then detects all clicks that match the selector, in your case the link elements. This is the most efficient way of catching all link clicks.
In testing document.location.href, I have observed that when the user initiates an action that results in javascript that assigns to document.location.href, the new URL is added to the history.
However, if the call is initiated by javascript that is result of, say, state change of an XMLHTTPRequest, the entry for the current page in the history is over-written. Have I characterized this correctly? Is there a way to get the page change to be reflected in the history in this latter case?
I was facing the same problem and found this workaround which worked for me
instead of
function onAjaxCallback(evt){
location.href=newLocation;
}
i wrapped the location.href call around a setTimeout. Seems to do the trick. My history's behaving fine now. Hope that helps
function onAjaxCallback(evt){
setTimeout(function(){
location.href=newLocation;
},0)
}
You could change the location without having the browser display a Back button like this:
window.location.replace(new_url);
However, the original address remains in the browser's history and may be accessed using something like CTRL+H
Reference:
https://developer.mozilla.org/en/DOM/window.location#replace
https://developer.mozilla.org/En/DOM/Window.history#Notes
study: window.location.replace() and window.location.assign()
URL can be manually added to history before redirecting the user.
if (window.history) {
history.pushState({}, window.location.href);
}
window.location.replace("/login/?next=" + window.location.pathname);
Read the original question more carefully. The question is not about content loaded by an XHR, but about content loaded by a script loaded by an XHR. I had the same problem and the setTimeout method seems to work well.
Alas, your question can't be answered, AJAX requests have nothing to do with browser history, and if you loaded some dynamic content with them, then the user clicked the browser back button, the previous page is loaded (this which was loaded with an ordinary GET or POST request), which corrupts the sequence you display content in.
Dmitri's answers means that you will maintain your own history for the dynamic content using the fragment part of the url (this after the # symbol), maybe you'll provide your own back and forward buttons, but still you're not protected from the effect of the browser back and forward buttons.
If only they had provided some kind of events to handle user clicks on these buttons with the ability to cancel.