Until now I believed that it was not possible for the HTML source of a page to be modified without reloading it entirely. I suspect what I've just seen is somehow related to pushState (but not only that): on the Quartz website (qz.com), you seamlessly slide to the next article once you've reached the bottom of the one you're reading, with a clean update of the URL and, amazingly, an updated HTML source.
For an example, scroll down any article, e.g.: http://qz.com/643497/we-are-witnessing-the-rise-of-global-authoritarianism-on-a-chilling-scale/
Maybe I've missed something, but could someone explain how this is done? Which HTML5 APIs are being used here?
NOTE: My question specifically focuses on updating the HTML content which you can seen when displaying the page source (not the DOM inspector, obviously).
This looks a lot like your typical asynchronous content loading, but yes they are using pushState to change the url. What is getting you I think is the fact that the routes are well-designed so that going to that URL gives you that same article first. However behind the scenes it is all just a series of JSONP requests combined with pushState() to give a nice flowing, well-formed document. You can even verify the requests using the network tab of any modern debugging console.
See this answer for info on using pushState for url updating :Modify the URL without reloading the page
EDIT
Since you are getting stuck on the fact on how the source is changing, think about it this way: When I say "the routes are well-designed so that going to that URL gives you that same article first" I mean that going to that page will reflect that article. All you are doing by viewing the source is taking the active URL (modified by pushState, so you are really going to a different page to retrieve the source) and grabbing the text without DOM parsing/rendering. I hope that clarifies what is going on in this site in particular.
You can now do this in most "modern" browsers!
Here is the original article I read (posted July 10, 2010): (HTML5: Changing the browser-URL without refreshing page).
For a more in-depth look into pushState/replaceState/popstate (aka the HTML5 History API) see the MDN docs.
you can do this:
window.history.pushState("object or string", "Title", "/new-url");
Related
As RIAs and SPAs (or web apps with heavy javascript usage) have become more and more popular, I've been running into systems that, instead of using good old a href hyperlinks, I see them utilizing constructs using onclick with JavaScript code that manipulates navigation. This is particularly true with images.
For example, instead of seeing something like this:
<img src="...."/>
<div ... onclick='SomeJsFunctionThatNavsToAnotherPage()'><img src="..."/></a>
What is the advantage of this? It makes it incredibly hard to trace where pages transition to when debugging or trying to root cause a bug. I can get the idea when the target to navigate can change (so yes, here you could use a function that computes to what page to navigate to.)
But I see this pattern even when the pages to navigate to are constant. I find this extremely convoluted and hard to test. Not to mention that there is always the browser-specific bugs that come from stuff (sadly in my experience from over-complexifying the front-end.)
But I am not a RIA/SPA developer (just backend and traditional web development). Am I missing the rationale behind this?
TO CLARIFY
My question is not for the case when we want to redraw the page or change current content without changing the current location. My question is for plain
old transitions, from page A to page B.
In such a case, why use onclick=funcToChangeLocation() over <a href="some location"/>.
This has been a pain for me when troubleshooting systems that are already written (for I wouldn't write them like that), but there could be reasons I am not aware of.
Again, my question is not for pages that redraw themselves without changing the browser location, but for navigation from one page to the next.
ALSO
If you are going to vote to close this question, at least leave a message explaining why.
If you are making a web application, sometime you don't want to redirect the user to another page, but you want to dynamically change the content of the page without refreshing the page. It has some advantages. It can be faster. You can easily keep the state of the page/application. You are not obligated to communicate with the server. You can update only a part of the page.
You can also dynamically request data to print the page. If you are displaying an user profile page, you can only ask a json object that represent the user. This json object is smaller than the whole page and will be dynamically rendered. It can help to reduce the data transfer between users and server when your bandwidth is limited.
EDIT: In the case of a simple page redirection, I think it's a bad practice and I cannot see an advantage. I think it obfuscate the website when the google crawler try to parse the website.
I once had a pretty successful web directory website. One day Google decided that "directories" are competing businesses and started penalizing sites that had links on directories. I used the method you describe to cloak outgoing links to try and trick Google.
I see this site and many others answering similar questions, but often in ways I fail to understand or just do not make sense. And often in contradictory ways (maybe the spec keeps changing?). And I see posts about how to set up cross domain JavaScript communication, but I do not need to communicate with this external content (and I am still not sure if you must have access to the code-base of both child and parent or not, for these hacks to work).
I need to show another person's webpage, on another domain, in a box on my page.
SO basically this is like clicking a link, but instead of specifying that the browser should open this in a new tab or a new window, I want the browser to open it in a in-line frame type deal on the current page. So even I know enough about security to know that there are no security/communications issues with this feature.
But assuming that the browser developers have removed this completely reasonable feature, how do I go about doing this? I have heard talk about some Json data type thing being allowed, but still have not figured out exactly what that means. Can I contact any random external page and get some json summery of the page, or how does this work? (I saw an example with Wikipedia, but I was not sure exactly what was being returned, and if any random URL would work just as well).
I can use PHP for this, but that is just stupid. I would basically just be setting up a proxy to access content I am randomly banned from because of the programming language I am trying to access it from.
You are looking for iFrames. Note, however, that there are many security restrictions due to potential cross-site scripting vulnerabilities through improper implementation.
You can change the source of that internal frame by simply editing the source attribute of that iframe
This article makes a pretty convincing argument that because URLs are long-lived (they get bookmarked and passed around), they should be meaningful, and that using the hash for real routing (determining what data is shown on the page and/or the state of the application) is thus improper. When I try to actually do that in my single-page application, though, I run up against a problem: how do I render my links so that all browsers can use the application? As I see it, there are three options:
all hrefs have a #/ prefix. This works great in HTML4 browsers. In HTML5 browsers, I can add a Sammy route that redirects to the hash-less version, which also works great. There might be a problem with browsers marking links as visited when they're not or not marking them visited when they are. The other problem is that it's... wrong. Anyone who shares a link by right-clicking it and selecting "Copy Link URL" will be sending a working but kludgy URL around.
no hrefs have a #/ prefix. As far as I can tell, HTML4 browsers will have no way of intercepting these link clicks, which means that every one will cause a page refresh. Though the application would probably still function, since I could use Sammy routes to rewrite the hashless versions to hashy ones on page load, the page loads would kill the performance of the single-page application.
I dynamically determine whether to prefix with #/ or not. This means that all of my links have to have dynamic markup and dramatically complicates the application.
The hash value of a URL never caused and entire re-load of page. Not in HTML4 and before that. A hash value has always been an internal link, and therefore it can be used perfectly (take a look at twitter for example). Of course, when you refresh the page, you will reload the page. But that is obvious.
With JavaScript you can actually read this hash value (see also this question/answer: How can you check for a #hash in a URL using JavaScript?) using window.location.hash
Using a more recent browser, you can also detect a hash change, which is useful if users actually change the URL: On - window.location.hash - Change?
But when you, as the website, change the URL you don't need read this, you already know because you just changed it.
This way, using hashes, people can exchange the URLs, and you can actually read which URL they are requesting, and therefore it should work perfectly.
I have a search engine on my website and it works via ajax. I want to have a specific <title> for each search attempt. To achive that I have to alter every time after I recieve a response from ajax.
Do you have any idea if googlebot will see this altered and use it to index my webpage?
Thanks for any help!
Do you have any idea if googlebot will see this altered and use it to index my webpage?
Most likely not.
You should change the title on server side.
Google bot does something similar to opening the page URL using notepad. It will see the JavaScript code as a plain text, which tries to change the title; but it will not see the result of the script execution of course.
EDIT:
Ajax enabled web pages are crawled using the same principle, unless they follow the techniques for Ajax-enabled web sites, as suggested by google:
AJAX crawling: Guide for webmasters and developers
Well, google added many features to its search engine over past years, and probably it will be able to see the changes. But how do you imagine a client should reach a page which address doesn't change, but content does after few clicks? You must combine AJAX with normal separate pages; this will also add compatibility for clients that have JavaScript disabled. E.g. have all pages redirect to the one working with AJAX if JavaScript is enabled and user-agent string doesn't match *bot*.
Simply, Google will not index any dynamic content from your page.
As Slava said, Google added many features to its search engine over past years, and probably it will be able to see the changes. But even if Google does eventually start indexing dynamically changed content, I think it is still uninteresting from a search engine optimization standpoint that those content will not be indexed as quickly as the others served from server.
It's important to know what you're getting and what you're losing. Yes, you may be adding functionality to your page easily and enhancing the user experience, but if you don't get the data indexed, you lose all that juicy keywordy goodness. :)
Hi i'm looking for a tutorial for understand how i can create a page with a div that isn't refreshed when the page url changes.
Ex. The facebook chat isn't refreshed when i move from an url to another.
Thanks
AJAX is definitely being used, although it may not seem like it because the actual URL is changing. Most AJAX apps just change the hash part of the URL (somesite.com/page/#feature1).
I don't know exactly what Facebook is doing as I haven't studied the app, but I would guess that they are using HTML5 history.pushState() to change the URL so that if you bookmark it or reload, it will go to the same place. I see that #Felix already mentioned this in a comment.
Take a look here for more help:
Is there a way to change the browser's address bar without refreshing the page?
There are lots and lots of resources on using AJAX. I personally use jQuery and find that it makes much of this quite easy. Here's a tutorial that might help:
http://net.tutsplus.com/tutorials/javascript-ajax/5-ways-to-make-ajax-calls-with-jquery/
Sounds like you are wanting to use AJAX (javascripts XMLHttpRequest function). here is a great article on it along with some basic examples: Here
It's called AJAX, if you use jQuery, here's a good tutorial:
http://yensdesign.com/2008/11/creating-ajax-websites-based-on-anchor-navigation/
I wanted to post another examples if you dont use jQuery but i need more points to post more than one link, sorry...