The portion of the URL (including and) following # is the fragment identifier . It is different from the rest of the URL. The key to remembering is only the "client side" (of course, the client can choose to send it to the server ... just not as a fragment identifier):
The fragment identifier works differently than the rest of the URI: it is processed exclusively on the client side without server participation . Of course, the server usually helps determine the MIME type, and the MIME type determines the processing of fragments. When an agent (such as a web browser) requests a resource from a web server, the agent sends a URI to the server but does not send a fragment. . The agent expects the server to send the resource, and then the agent processes the resource according to the type of document and its value.
This can be used to navigate to anchor links, for example: http://en.wikipedia.org/wiki/Fragment_identifier#Basics (note how this happens in the Basics section).
While it was used to just go to the “bindings” in the past, it is now used to store navigation state on many JavaScript-enabled sites - for example, gmail uses it heavily. And, as in this case, there is some “photorating” JavaScript that also uses the fragment identifier for state / navigation.
Thus, as expected, JavaScript “captures” the snippet (sometimes called a “hash”) and performs AJAX (or another background task) to refresh the page. The page itself does not reload when the fragment changes, because the URL still refers to the same server resource (the part of the URL before the fragment identifier).
New browsers support the onhashchange event, but monitoring has been supported for a long time by various polling methods.
Happy coding.
user166390
source share