Links to Named Anchors

Tinkersdamn

Links to named anchors inside of resources at SmugMug do not work properly.

The URI's appear to be mangled by SmugMug. The result is that, in situtations where the to/from link anchors are on different pages, the page returned is always positioned at the top, instead of at the location in the target page specified by the fragement identifier.

For example; href="/gallery/foo#bar" should return a resource "foo" and preserve the fragment identifier "#bar" in the URI so that the browser can position its view to the proper point inside of the resource.)

This works properly in SmugMug only when both the 'to' and 'from' anchors are in the same page (it still mangles the URI) but not if the pages are different.


Details, examples and plenty of discussion of this behavior is here at this thread.

This is a link to the w3c specification which describes how fragment identifiers should work. The link itself is also an excellent example of the proper behavior.

I've managed to use a less than perfect workaround so this is not urgent. Just wanted to get it logged as a bug. Thanks.

{JT}

Do you have an example page to your work around? I recently fixed a bug with the SmugMug viewing style where a gallery would not load if you sent a link with a hash tag that we did not expect (we look for ImageID, Page # or Lightbox).

However, if you are referring to a non-gallery page, then you are probably out of luck

Tinkersdamn wrote:

Links to named anchors inside of resources at SmugMug do not work properly.

The URI's appear to be mangled by SmugMug. The result is that, in situtations where the to/from link anchors are on different pages, the page returned is always positioned at the top, instead of at the location in the target page specified by the fragement identifier.

For example; href="/gallery/foo#bar" should return a resource "foo" and preserve the fragment identifier "#bar" in the URI so that the browser can position its view to the proper point inside of the resource.)

This works properly in SmugMug only when both the 'to' and 'from' anchors are in the same page (it still mangles the URI) but not if the pages are different.


Details, examples and plenty of discussion of this behavior is here at this thread.

This is a link to the w3c specification which describes how fragment identifiers should work. The link itself is also an excellent example of the proper behavior.

I've managed to use a less than perfect workaround so this is not urgent. Just wanted to get it logged as a bug. Thanks.

Tinkersdamn

{JT} wrote:

Do you have an example page to your work around? I recently fixed a bug with the SmugMug viewing style where a gallery would not load if you sent a link with a hash tag that we did not expect (we look for ImageID, Page # or Lightbox).

However, if you are referring to a non-gallery page, then you are probably out of luck

The site reference is above. But... mine is a practical workaround not a technical one. It is simply to point the user to the page with the content and place an unordered list at the top of the page that can be used to navigate to the intended target anchor. Since things seem to work properly inside of a page this is a workable solution albeit more complicated for users than it should be.

The code that parses the URI inside SmugMug needs to be changed to preserve the fragment identifier '#foo' in all cases and tack it back onto the URI that is returned to the browser. This is beyond my mere mortal capabilities.

I can only speculate that the original design intended to use the '#' correctly, and the fragment identifiers pointed to photos inside of gallery pages and that these locations were marked with anchors. But then someone got creative and bent the design so that the '#' was assumed to point to a pre-ordained set of anticipated objects which of course left the W3C standards in the dust. Just a hunch...

{JT}

I don't want to get in to how we develop the site too much here, but we do use redirects to build certain pages. For example, we don't have a million folders inside of the /gallery/ url that contain all of the albums for the site

Your problem has actually been my problem as well, since I would love to build a page using the fragment identifier without invoking javascript. What I found out is that the browser does not send the fragment identifier or hash tag to the server when it requests a web page. The browser only sends the important part of the URL - but keeps that hash tag for itself to use. (Some browsers MAY send the fragment identifier - but certainly not the majority of them).

The only work around I know is to have a little bit of javascript at the top of your page that looks for location.hash and reloads it if it finds anything (after the page loads).

I hope that makes sense, if not just let me know and I can try again

Tinkersdamn wrote:

The site reference is above. But... mine is a practical workaround not a technical one. It is simply to point the user to the page with the content and place an unordered list at the top of the page that can be used to navigate to the intended target anchor. Since things seem to work properly inside of a page this is a workable solution albeit more complicated for users than it should be.

The code that parses the URI inside SmugMug needs to be changed to preserve the fragment identifier '#foo' in all cases and tack it back onto the URI that is returned to the browser. This is beyond my mere mortal capabilities.

I can only speculate that the original design intended to use the '#' correctly, and the fragment identifiers pointed to photos inside of gallery pages and that these locations were marked with anchors. But then someone got creative and bent the design so that the '#' was assumed to point to a pre-ordained set of anticipated objects which of course left the W3C standards in the dust. Just a hunch...

jfriend

{JT} wrote:

Do you have an example page to your work around? I recently fixed a bug with the SmugMug viewing style where a gallery would not load if you sent a link with a hash tag that we did not expect (we look for ImageID, Page # or Lightbox).

However, if you are referring to a non-gallery page, then you are probably out of luck

JT, if you're looking for an example of where this doesn't work, it's in his previously mentioned thread. He has placed an anchor in a gallery. He wants to go directly to that anchor from another page. Here's the link that doesn't go to the anchor:

http://www.ravensphotography.smugmug.com/gallery/8285063_F7JU6#PORTRAITS

{JT}

Yes, I see. Some of these may not work until we have updated all of the styles to support ajax w/ fragment identifiers. Even then, we will have to work out a method to support old style urls.

jfriend wrote:

JT, if you're looking for an example of where this doesn't work, it's in his previously mentioned thread. He has placed an anchor in a gallery. He wants to go directly to that anchor from another page. Here's the link that doesn't go to the anchor:

http://www.ravensphotography.smugmug.com/gallery/8285063_F7JU6#PORTRAITS

Tinkersdamn

{JT} wrote:

What I found out is that the browser does not send the fragment identifier or hash tag to the server when it requests a web page. The browser only sends the important part of the URL - but keeps that hash tag for itself to use. (Some browsers MAY send the fragment identifier - but certainly not the majority of them).

The only work around I know is to have a little bit of javascript at the top of your page that looks for location.hash and reloads it if it finds anything (after the page loads).

I hope that makes sense, if not just let me know and I can try again

Well thanks, I did not know that. Learn something every day...

I think the problem then is that the URI returned to the browser is NOT the one that is sent to the server. It comes back different in most cases.

Here is what I see going on -

Assume - gallery URI is \gallery\n-k
Assume - gallery page contains an anchor with id="foo" (or name="foo") somewhere on the page,

Then -

CASE #1: STARTING POINT IS THE GALLERY PAGE (\gallery\n-k)
You click on an anchor containing an href=#foo you will be taken to the proper position inside the page (the spot containing the anchor with id="foo").

This now makes sense to me based on what you said about browser behavior. The browser already has the identified resource loaded so it just jumps to the anchor in the page it has cached and does not request anything from the server.

CASE #2: YOU ARE ON ANY OTHER PAGE
Your browser requests the URI -
\gallery\n-k#foo

the URI comes back mangled as -
\gallery\n-k\1\foo

but the same page gets returned. (i.e. same as if you had gone to \gallery\xxx-yyy)
And of course once it is loaded, since it is the same page and the browser now has it loaded, you can now get to the right place from there if you try \gallery\n-k\1\foo#foo.

But if you are coming from anywhere else then -

a link to ... takes you to ... (top of page)

---

\gallery\n-k#foo --> \gallery\n-k\1\foo
\gallery\n-k\1#foo --> \gallery\n-k\1\foo
\gallery\n-k\1\foo#foo --> \gallery\n-k\1\foo

I'm a bit surprised that the last one above does not work since the URI returned is the same as the one requested. I think the browser (I'm using FF 3.5.2) must not trust what is returned to be complete even in this case.

I'm not very experienced with how the browser does page processing but could it be that in the last case it does not look for the anchor because it invalidates the resource after it runs javascript on the page it just loaded? I have JS (Top JS) in this page to suppress links on the photos.

/* --- Journal No Link Images ------------                              */
/* This code enables a Journal style without the images being links */
function doOnLoad() {
  if (window.AlbumID && (window.AlbumID == "8285063")) //
  removeLinkFromImg();
}

function removeLinkFromImg()
{
    var links = document.getElementsByTagName("A");
    for (var i = 0; i < links.length; i++)
    {
        var link = links[i];
        var divElm = link.parentNode;
        if (!divElm)
            continue;
        divElm = divElm.parentNode;
        if (!divElm)
            continue;
        if (divElm.className.indexOf("photo")<0)
            continue;
        link.href = "javascript:void(0);";
    }
}
/* --- End: Journal No Link Images ----- */

[There is also "Bottom" JS to make the home page behave like a .gallery page]

{JT}

I get it now. I will see what can be done, I am pretty sure I know what the culprit is.

Tinkersdamn wrote:

Well thanks, I did not know that. Learn something every day...

I think the problem then is that the URI returned to the browser is NOT the one that is sent to the server. It comes back different in most cases.

Here is what I see going on -

Assume - gallery URI is \gallery\n-k
Assume - gallery page contains an anchor with id="foo" (or name="foo") somewhere on the page,

Then -

CASE #1: STARTING POINT IS THE GALLERY PAGE (\gallery\n-k)
You click on an anchor containing an href=#foo you will be taken to the proper position inside the page (the spot containing the anchor with id="foo").

This now makes sense to me based on what you said about browser behavior. The browser already has the identified resource loaded so it just jumps to the anchor in the page it has cached and does not request anything from the server.

CASE #2: YOU ARE ON ANY OTHER PAGE
Your browser requests the URI -
\gallery\n-k#foo

the URI comes back mangled as -
\gallery\n-k\1\foo

but the same page gets returned. (i.e. same as if you had gone to \gallery\xxx-yyy)
And of course once it is loaded, since it is the same page and the browser now has it loaded, you can now get to the right place from there if you try \gallery\n-k\1\foo#foo.

But if you are coming from anywhere else then -

a link to ... takes you to ... (top of page)

---

\gallery\n-k#foo --> \gallery\n-k\1\foo
\gallery\n-k\1#foo --> \gallery\n-k\1\foo
\gallery\n-k\1\foo#foo --> \gallery\n-k\1\foo

I'm a bit surprised that the last one above does not work since the URI returned is the same as the one requested. I think the browser (I'm using FF 3.5.2) must not trust what is returned to be complete even in this case.

I'm not very experienced with how the browser does page processing but could it be that in the last case it does not look for the anchor because it invalidates the resource after it runs javascript on the page it just loaded? I have JS (Top JS) in this page to suppress links on the photos.

/* --- Journal No Link Images ------------                              */
/* This code enables a Journal style without the images being links */
function doOnLoad() {
  if (window.AlbumID && (window.AlbumID == "8285063")) //
  removeLinkFromImg();
}

function removeLinkFromImg()
{
    var links = document.getElementsByTagName("A");
    for (var i = 0; i < links.length; i++)
    {
        var link = links[i];
        var divElm = link.parentNode;
        if (!divElm)
            continue;
        divElm = divElm.parentNode;
        if (!divElm)
            continue;
        if (divElm.className.indexOf("photo")<0)
            continue;
        link.href = "javascript:void(0);";
    }
}
/* --- End: Journal No Link Images ----- */

[There is also "Bottom" JS to make the home page behave like a .gallery page]