On a website that has several sections and subsections on one page, I was thinking about implementing scrolling to a new section as a new browser history event. The main reasoning for doing so is to allow for linking to a specific section of the page by keeping the URI in sync to the section currently viewed by the user. I.e. on a page http://mypage.com/apage/ scrolling to the second section of the page, the browser address would change to http://mypage.com/apage/section2/ without any page refresh, and also enter this new URI as a history point to the browser's history.

Similarly, I have a lightbox overlay in some of the sections. I want to register a history event for having the overlay opened with a specific content. Here, too, the reasoning is that I want users to be able to link to something like http://mypage.com/apage/section3/subsection2/lightboximage4/ and people clicking this potentially shared link open the page scrolled to section3, subsection2, with lighboximage4 open.

Is the entering of history events like scrolling to a section or opening an lightbox overlay confusing? I imagine a scenario like someone browsing different pages, then scrolling to a section and clicking back to return to the previous page - with the result of scrolling up one section, because that was the last history event.


Do the advantages of well structured URI's outweigh the potentially harmful effect on usability, or am I worrying about a problem that is none?

What other situations or events could be equally problematic to programmatically insert into the browser history?

Should I detect history back events and internally redirect to user as far back in the history to what I deem the real last history event (i.e. actual different page view or top section change)?

  • Implementation note: I don't think you can change the URL without reloading the page unless it's an HTML5 browser (won't work on IE9 and earlier). – obelia Dec 11 '12 at 17:45
  • @obelia location.replace seems to work in IE7 :) I don't have 8 or 9 to test it on at the moment though.. – gotohales Dec 11 '12 at 17:52
  • @obelia you actually can, and there is a solution with integrated fallback for older browsers - implementation, however, is not my real concern here :) – kontur Dec 11 '12 at 18:07
  • Thanks @kontur, I'm working on similar (history/URL) problem! – obelia Dec 11 '12 at 18:11

The "#" fragment URL is the standard way to indicate a location on a page and the history management for that is already build into the browser (basic example).

The lightbox state could also be encoded in hash fragment URLs, I think this is standard enough behavior that wouldn't pose any usability problems.

  • Heh basically what I was referring to :) – gotohales Dec 11 '12 at 16:22
  • While the fragment identifier is the established way to specify in-page links I was considering page hierachy and SEO to take advantage from transforming the URI alltogether according to what happens on the page. Either way, fragment identifier or not, my question is more about the usability implications of using such a system. Do you think using the fragment identifier instead of an dynamic URI rewrite would help make it more transparent to the user what is happening? – kontur Dec 11 '12 at 16:48
  • 4
    @kontur - Yes I think there are definite usability issues regarding the URL. The hash fragment means a location within the page (to users), whereas a whole new URL means a whole new page (usually). – obelia Dec 11 '12 at 17:36

Interesting question. People generally expect the back button to take them back to the previous page, rather than back to an arbitrary point on the same page. By that logic, one should only add an event to the browser history if the transition from one view to another appeared, from the user's perspective, to be from one page to another page. People are unlikely to associate the act of scrolling up-and-down with moving between pages, even if it's triggered by clicking on a link.


If the main goal is to allow users to bookmark various locations on the site, why not use URL variables that change as the user navigates the site?

This would allow the browser history to remain untouched and work as the user expects, and likely reduce the work load of trying to make it perform a lot of abnormal functions.


If this is a potential solution, I will try to explain what should work without going too deep into code. If you were to set events on either scrolling (using something like jQuery Waypoints) or on your lightbox clicks, you could update the hash with something like


which will update the hash in the URL but not affect the history in any way. This will allow you to freely update and change the hash based on the user behavior, but not force them to use the back button multiple times to return to where they were.

A bit more code would have to be added to make the bookmark links initialize the state of the URL, but more information can be found at here on that.

Hope this helps! :)

  • From your comment on @obelia's answer, I gather you refer to the fragment identifier with URL variables, which in turn does touch the browser history, contrary to what your answer states, does it not? – kontur Dec 11 '12 at 16:44
  • @kontur Usually it would, as that is the intention, but in your case I could see it not doing that as making more sense. I updated my answer to show how that would work. – gotohales Dec 11 '12 at 17:26
  • @kontur Oh and I forgot to mention, by URL variables I meant the hash, as well as what is available in other languages like PHP, using the question mark. Wasn't sure what language or scripting freedoms/constraints you were working with. – gotohales Dec 11 '12 at 17:40

I think that autoscrolling a page to some section specified in a shared (or saved) link is a bad idea.

The problem is with scrolling. I mean, if you use anchors (i.e. '#' parts of an URLs) in a regular way, browser will open the desired section (a section anchor points to) in front of users eyes quickly.

And sometimes it doesn't happen quickly (heavy page which is still loading, etc) . I.e. user have to wait until something unknown will happen to get the content. The worst thing is that there is no any visual aid of that (i.e. user may even don't know he or she have to wait to be relocated or scrolled to the right section, etc).

So, in your case, user will see the whole thing, will start to look at the page and then everything will begin to scroll and change. That's really really annoying.

So, I think you should not touch URL at all (and let users to use a navigation), or avoid changing the page layout after the page was loaded or do it very quickly so user will not notice this change at all.

  • have you seen this exact mechanism as work? for instance, try going to the link of this answer (obtained through the "Share" option):ux.stackexchange.com/a/30663/17246. – Dvir Adler Dec 17 '12 at 11:29
  • @DvirAdler surely, I know how it works. This page is "light" and loaded fast and there is no problem with it. I'm talking about other cases, where page content is modified after page load or any manual animations are used, etc. – alexeypegov Dec 17 '12 at 17:13

This is a problem we tackled in products as well. Our issue was for the do/undo stack, rather than sharing. In our case, some undo would have significant impact on the navigation of the user. We handled it by adding navigation actions to the undo stack. This is a similar approach to what you are talking about.

I also had a talk from Jeff Heer, prof at Stanford, from when he was working on ManyEyes. He had a similar approach to yours to accommodate referring to content within a page. i believe that with single-page web app pattern becoming mainstream, this approach will become the norm quite rapidly.

Your Answer

