8 replies to this topic

[HartleySan]

I've been reading recently about how to create a working back button in Ajax as well as how to create linkable and bookmarkable pages. Making linkable and bookmarkable pages isn't too bad, but when it comes to making a back button, it seems to get a bit "hacky".

The two main solutions I've seen are to poll the page every second or so (with setInterval, etc.) and constantly check whether the real URL matches the URL retained by JS, and when they're different, work your Ajax magic to make a page transition, and the other (to me, better) solution is to insert a hidden iframe into the page.

Apparently, when content in an iframe is changed, it counts as a page transition, so it activates the back button, even though it doesn't look like anything has changed on the page. You can use the iframe to send info to a separate (PHP) script, and then get that info back to make the necessary Ajax transition.

Of course, there is the third option of simply not using Ajax at all, but at this point, I think we all see the appeal of Ajax, so I'm not even really considering this. Naturally though, I think having linkable and bookmarkable Ajax pages are essential, so I want to get everyone's opinion on what they think the best option is.

Thank you.

[Larry]

It would seem like the iframe solution is better, although I'm not an expert on that particular approach. Do you know what the downsides are to using an iframe?

[HartleySan]

Not particularly, no. More easily hackable?

[HartleySan]

I looked into it a bit more, and (as I suspected) the main issue with iframes seems to be related to SEO. That's all well and good, but I really don't see any other reasonable way of getting Ajax to work with the back button.

The way I see it, until big improvements are made to JS and whatnot, it's really not my concern to try and satisfy certain SEO requirements when it seriously sacrifices the usability of the site. Furthermore, I would think Google (of all places) would be smart enough to have already found a way around this issue for the sake of search results.

[Antonio Conte]

How about including the polls instead and work out anorher update mehanism? Is that a possibility?

[HartleySan]

Well, the polling is the update mechanism. Basically, you use the setInterval method in JS to check the URL every 1 second or so. If it ever differs from the URL that you keep stored in a variable in JS, then you know that the user hit the back button (or the forward button), and basically before the user can really notice that them hitting the back button was intercepted by you, you override that behavior with an Ajax call to get the proper content.

To be honest with you, I don't completely get this method and have not implemented it myself, but I haven't bothered to research it thoroughly because it seems to be the older and "less good" of the two hacks. In other words, the iframe method seems to be preferred.

If you use the setInterval method to check on something, it can cause a huge strain on the system.

[HartleySan]

I did a little more research, and it's looking like SEO will actually not be an issue.
I recently read the book "Search Engine Optimization Secrets" (for the second time) by Danny Dover, and he states that no "link juice" (i.e., the stuff that links pass to the pages they're linked to and that causes pages to be ranked higher in search results) is passed to frames or iframes.

Normally, this would be bad, but in this case, since the iframe is used as a means to replicate the back and forward buttons, and is not intended to be seen by the user, it actually doesn't matter (and is probably a good thing, because it will stop the iframe script from potentially being ranked by search engines).

Anyway, Larry, if there are some other pitfalls to using iframes, please inform me. Otherwise, I think I'll go the iframe route.

[Larry]

To be honest with you, I don't completely get this method and have not implemented it myself, but I haven't bothered to research it thoroughly because it seems to be the older and "less good" of the two hacks. In other words, the iframe method seems to be preferred.

That is awesome. "I don't understand it and I haven't tried it, but I may have read somewhere that it isn't as good." Admirable decision making there.


If you want to do the iframe, do the iframe. SEO shouldn't be a concern (99% of SEO comes down to having good content anyway). But is your iframe solution bookmark-able? Without changing the hashtag, I couldn't see that it would be. I don't know if that's a requirement or not, but it's something to check.

Also, if dynamically manipulating the history is a critical component, have you considered using a library (such as History.js) that would use the HTML5 history management, if supported, and gracefully fallback to the HTML4 hashtag manipulation if not?

[HartleySan]

Thought about using a library to manipulate the history, but I don't usually like adding excess libraries if it's for something I can do on my own.

The iframe method does not require any manipulation of the history anyway though, so it's cool.
Also, I have a PHP-only back end set up so JS is not required to link to any page, but the JS/Ajax solution does solely rely on the fragment identifier for all bookmarking, yes.

A small price to pay. Nowadays, almost all browsers in use have JS enabled and support Ajax, so not too worried about that.