Hacker News Reader

Comment by amackera | Hacker News Reader

Steps to reproduce broken button:

  1) Open the demo page
  2) Click image
  3) Click 'X' in top left of image
  4) Click different image
  5) Click the 'X' in the top left of image
  6) Click browser's 'back' button
  7) Observe how you're staring at the image, not the hacker news page you came from.

The problem is that clicking the 'X' should pop the image off the stack, not just add another page ("#home") to the stack.

Opening an image then hitting back works as it should, though.

View on HN

Here's another demo to reproduce the "broken" back button:

  1. Go to http://en.wikipedia.org/wiki/Hacker
  2. Click the "Innovation" link in the ToC on the right
  3. Click the "Entertainment" link (you can just see it) under the "Innovation" one.
  4. Click the back button.
  5. Observe how you're not taken back to Hacker News.

Now imagine this is a really long page of FAQs, with a "Return to top" after each question, and the same ToC at the top (something a clueless user probably sees everyday [I know I do on O2's site all the time]). You can see how it begins to look like a browser implementation problem.

Maybe the browser should automatically pop all "#<identifier>"s associated with a URL from its history stack if a user reaches the original URL again (via backs or clicking some in-page link, doesn't matter); I don't know. But I honestly consider this a browser implementation problem, not a web developer problem. I think anything we've been doing till now has been to mitigate this and we shouldn't have to.

The solution is not to change browser behavior, that's fine. Just remove the hashtags from the images so the URL doesn't change when you click on the picture.

Does that make it "broken" or just incompatible with your expectations? Would other non-technical users have the same expectations? It's possible other users will want to go "back" to the image they last visited.

Consider if this was done just HTML 4 and no CSS or Javascript. You would click a thumbnail and a new page would be loaded with a full size version of the image. You would then click a "close" button that would take you to the page with the thumbnails again. If you hit "back" you would go back to the image.

The way the page currently works follows the "stack" of what I actually visited by clicking links. If I want to reverse my workflow after visiting all 5 images and closing between them, I personally would expect the back button to go through all 5 images. From this perspective, doing the same effect with Javascript that doesn't update the stack might surprise me if after clicking 10 links on this page, a single click of the browser back button skips 10 steps of my workflow and returns me to HN.

I understand your argument, and it makes sense; however, I disagree.

The user clicks the image in order to see it full-size. The lightbox overlays the page that the user is on. The user is not conscious that they are navigating to a new page, or even just a part of the page that they weren't at before (to the #image). Though the workflow is in actuality following a link, the user is not aware that they are following a link, so the back button functionality doesn't work as expected.

Links are well understood by everybody that uses the Web. They change the page that you're on to a new page, or a new part of the page. Lightboxes were invented so that the user doesn't need to leave the page, or the part of the page, that they are on.

So in my mind, lightboxes that don't behave like lightboxes and instead behave like links are broken.

I don't have any experience with developing lightboxes but couldn't the 'X' button just use javascript to go back in the history (instead of directly hiding the image). Or is that how most lightboxes work but because this one cannot use javascript it is not possible to do so?

Reply on news.ycombinator.com